Microsoft y las empresas tecnológicas apoyan la difusión de la IA de código abierto

Microsoft, junto con más de dos docenas de empresas de tecnología, están presionando a los formuladores de políticas para que apoyen sistemas y códigos de inteligencia artificial de código abierto en toda la sociedad, argumentando que será un enfoque más seguro que intentar restringir el acceso o depender de un puñado de modelos cerrados y propietarios.

El carta abiertapublicado el viernes, establece paralelismos con el industria del software de la década de 1980cuando las grandes empresas temían que el código de software de fuente abierta afectara sus negocios. Si bien la industria perdió esa batalla, el resultado final fue un ecosistema vibrante que ahora sustenta gran parte de la Internet moderna, la TI gubernamental e incluso los productos de software comercial.

También creó una “base compartida de conocimiento” que ha alimentado innumerables proyectos e innovaciones de software futuros.

«Estados Unidos se enfrenta ahora a una elección similar con la inteligencia artificial», escribieron las empresas. «Nuestro liderazgo en IA no será juzgado por un modelo de IA de frontera, sino por si Estados Unidos construye un ecosistema fuerte y abierto que se difunda en todos los sectores».

Ampliar el acceso y el soporte a la IA de código abierto conlleva un riesgo de seguridad significativo. Los expertos en ciberseguridad advierten que uno de los mayores beneficiarios de las herramientas de inteligencia artificial ampliamente disponibles son los delincuentes de bajo nivel que hasta ahora carecían de la experiencia técnica o los recursos para lanzar ataques graves.

Una vez que un modelo está abierto, cualquiera puede descargarlo, personalizarlo, quitarle las barreras y usarlo para sus propios fines. A medida que los modelos de código abierto han mejorado en la creación de deepfakes y otras imágenes generadas por IA, el peligro de CSAM personalizado localmente y deepfakes sexualizados también podría crecer.

Pero la carta sostiene que los modelos de IA de peso abierto son más beneficiosos para las empresas emergentes, las universidades, los laboratorios de investigación y otras organizaciones pequeñas y ambiciosas que pueden innovar e iterar la tecnología y hacerla más útil para la sociedad.

«Los pesos abiertos permiten que cada organización combine el modelo correcto con el trabajo correcto al costo correcto, reservando capacidad a escala de frontera para problemas de frontera genuinos y ejecutando modelos especializados eficientes en todos los demás», escribieron las empresas. «Esa disciplina es lo que hará que la IA sea económicamente sostenible a medida que su uso se extienda a miles de millones de tareas cotidianas».

Específicamente para la ciberseguridad, la carta sostiene que los defensores armados con IA de código abierto superarán a los atacantes mejor que cualquier enfoque de modelo cerrado.

«En un mundo donde los atacantes de la ciberseguridad utilizan IA avanzada, los defensores necesitan acceso a modelos con capacidades comparables para poder detectar, simular y responder a amenazas emergentes», escribieron las empresas. «Los modelos abiertos amplían la capacidad defensiva, aumentan la transparencia y permiten descubrir y remediar vulnerabilidades en muchos equipos».

Otras empresas destacadas que firman la carta son Meta, Palantir, Perplexity, Mistral, NVIDIA, Mozilla, The Linux Foundation, Hugging Face, Dell Technologies e IBM.

Los formuladores de políticas estadounidenses continúan luchando por lograr un equilibrio entre el apoyo desenfrenado a la industria nacional de IA y la supervisión y regulación de los daños que resultan de su uso.

La administración Trump ha pasado por varios marcos desde que asumió el cargo, primero un enfoque de laissez-faire sin restricciones, luego una orden ejecutiva que crea un régimen de pruebas voluntarias para la industria, luego la imposición de controles de exportación en el modelo Fable de Anthropic y, según se informa, presionando a OpenAI para que retrase el lanzamiento de sus modelos por preocupaciones de ciberseguridad.

La carta llega cuando la administración Trump ha supuestamente considerado una orden ejecutiva que restringiría el acceso y la disponibilidad estadounidense a los modelos de código abierto fabricados en China.

Pero la Casa Blanca y las empresas estadounidenses están tratando de hacer algo al reconocer los beneficios generales de un enfoque de código abierto, al tiempo que se muestran cautelosos a la hora de hacer cualquier cosa que pueda beneficiar potencialmente a sus rivales chinos.

A principios de este mes, la Casa Blanca anunció la creación de su centro de intercambio de información sobre ciberseguridad de IA Gold Eagle, que ayudaría a coordinar el trabajo del gobierno, el sector privado y la sociedad civil para encontrar y cerrar las vulnerabilidades descubiertas por la IA. Una gran parte de ese esfuerzo, dijo un alto funcionario de la Casa Blanca, es apoyar a los proveedores y mantenedores de herramientas de inteligencia artificial de código abierto.

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Los agentes de inteligencia artificial de Android de código abierto podrían permitir que el texto de la pantalla invisible ejecute código en las PC host

Una aplicación de Android que puede dibujar sobre otras ventanas y escribir en un almacenamiento compartido puede enviar instrucciones al agente de inteligencia artificial que maneja ese teléfono, en un texto que ningún ojo humano verá jamás. Dos pasos más y la misma aplicación ejecutará comandos en la PC que controla al agente.

Los investigadores demostraron esa cadena, además de otros seis ataques, contra cinco marcos de agentes móviles de código abierto: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM y MobA. Todos cayeron al menos a seis de los siete.

El papel subió en arXiv el 1 de julio y fue revisado el 14 de julio. Los autores están en la Universidad Simon Fraser, la Universidad China de Hong Kong, la Universidad de Shandong y el Laboratorio Xingtu de la empresa de seguridad china QAX.

Nada aquí tiene un CVE, y el primer autor Zidong Zhang dijo Las noticias de los piratas informáticos el equipo no tiene evidencia de que las técnicas se hayan utilizado fuera de un entorno controlado. Hacker News revisó los cinco marcos y encontró las rutas de captura de pantalla, la llamada de shell y el respaldo de transmisión que el periódico describe todavía en sus ramas principales a partir del 17 de julio.

Zhang dijo que el equipo envió un correo electrónico privado a los mantenedores afectados antes de publicar la preimpresión y «no ha recibido respuesta hasta la fecha».

La escalada es la parte menos exótica. AppAgent’s controlador ejecuta subprocess.run(adb_command, shell=True) y crea entradas de texto colocando la salida del modelo directamente en el texto de entrada del shell adb {input_str}. La lista del periódico muestra que la función no tiene ningún tipo de desinfección.

El código en vivo funciona marginalmente mejor y no es suficiente: elimina espacios y comillas simples antes de interpolar, y deja el resto de los metacaracteres del shell en paz. No;, no &, no >. Entonces, una cadena que el modelo lee en una pantalla y escribe diligentemente es dividida por el shell del host, y la mitad posterior se ejecuta en el cuadro de Windows del operador.

Una carga útil diseñada para iniciar calc.exe hizo exactamente eso en 20 de 20 pruebas contra AppAgent, AppAgentX, Mobile-Agent-v3 y MobA. Una ejecución separada de un extremo a otro contra AppAgent utilizó test;pwd>rce_success y escribió el directorio de trabajo del host en un archivo.

Ciberseguridad

Poner esa cuerda delante del modelo es una carrera de archivos. Abrir-AutoGLM ejecuta screencap -p /sdcard/tmp.png y luego un adb pull por separado. Agente-móvil-v3 escribe en un /sdcard/screenshot.png fijo y duerme medio segundo entre los dos. AppAgentX escribe en /sdcard/ con nombres de archivo con marca de tiempo que llevan un contador de pasos incremental, un patrón que un atacante puede observar. AppAgent enviado configuración.yaml todavía tiene como valor predeterminado su directorio de captura de pantalla /sdcard.

Los investigadores calcularon esa brecha entre los marcos entre 50 y 500 ms, con un promedio de alrededor de 210 ms en 100 ejecuciones. Un servicio en segundo plano que sondea cada 5 a 10 ms tiene espacio para bloquear un archivo, volver a pintar el PNG y soltarlo antes de que el agente lo recopile. La manipulación aterrizó 19/20 a 20/20 contra cuatro de los cinco.

Para ampliar aún más la ventana, le mostraron al agente una superposición invisible que decía que se estaba ejecutando una sincronización de red y le pedían que esperara tres segundos. La modelo lo creyó.

Los seis modelos de visión que los investigadores probaron leyeron texto con una opacidad del 2% en al menos 18 de 20 ensayos de laboratorio. El documento sitúa ese nivel por debajo de la detección humana típica bajo una visión normal. GPT-4o, Claude Opus 4.5, Gemini 3 Pro y GLM-4V obtuvieron 20 sobre 20. Los números no aumentan a medida que el texto se vuelve más visible, porque comienzan en el techo.

AutoGLM-Phone, un modelo 9B que se ejecuta en el propio dispositivo, fue el más débil de los seis con 18 de 20. La visión humana aplica un umbral. La captura de pantalla no.

La asimetría también tiene una versión de hardware. Los teléfonos redondean sus esquinas y hacen agujeros para las cámaras, pero el búfer de cuadros permanece rectangular, por lo que los píxeles representados en esas regiones se ubican debajo del bisel y aparecen en cada captura de pantalla. En un Pixel 4, eso deja alrededor de 78 píxeles de ancho oculto en una esquina, suficiente para un comando corto, y los cinco agentes leen cargas útiles.

Un tercer truco evita por completo el sigilo: un servicio de accesibilidad coloca una actividad de inicio de sesión falsa sobre la aplicación real y permite que el agente escriba las credenciales del usuario en ella. Una persona podría dudar ante una solicitud de contraseña inesperada. Ninguno de los cinco lo hizo en 100 ensayos.

Nadie autenticó el teclado.

Los agentes no tienen un canal autorizado para acceder a un teléfono, por lo que reutilizan los de depuración, y de ahí sale el ataque más barato del conjunto. Open-AutoGLM codifica en base64 el texto que escribe y lo dispara en ADB_INPUT_B64, una transmisión implícita recogida por Teclado BADuna herramienta de automatización de pruebas creada para aceptar texto de cualquier cosa que lo transmita.

Ese es su propósito documentado, y aún se mantiene, con una Prelanzamiento de abril lleva una solución de Android 16. ADB Keyboard hace lo que promete su README. Los agentes son los que convirtieron un arnés de prueba en una tubería de entrada de producción.

Mobile-Agent-v3 mantiene una lista de permitidos estrecha: las letras, los dígitos y la puntuación común van a través del texto de entrada del shell adb, y todo lo demás, es decir, cualquier carácter que no sea ASCII, sale un carácter a la vez a través de ADB_INPUT_TEXT. Moba es más contundente. Su type_text prueba toda la cadena con text.isascii(), por lo que un emoji o una letra acentuada en cualquier parte de un mensaje envía el mensaje completo a través de la transmisión en una sola toma.

Cualquier aplicación que registre la misma acción recibe la misma carga útil y no necesita permiso para hacerlo, por lo que nada advierte al usuario. Cuando un atacante tiene accesibilidad, TYPE_VIEW_TEXT_CHANGED entrega el mismo texto en texto plano, incluidos los campos de contraseña, en los cinco.

Las condiciones previas son reales. Esto requiere una aplicación ya instalada, un agente en mitad de la tarea y la depuración USB o inalámbrica habilitada. El software afectado son herramientas de desarrollo de código abierto, no el asistente integrado en un teléfono estándar.

Los agentes propios, incluidos Bixby de Samsung y XiaoAi de Xiaomi, estaban fuera de alcance, al igual que iOS. Zhang hizo una advertencia: varios de los ataques necesitan permisos mínimos de Android, y uno no necesita ninguno en absoluto, lo que, según él, reduce la barrera para un atacante motivado.

Una variante tampoco necesita ninguna aplicación maliciosa. Debido a que una carga útil puede viajar en los canales de crominancia de una imagen en lugar de su brillo, un atacante que nunca toque el dispositivo podría enterrar una en una imagen y dejar que el propio agente de la víctima la capture desde una aplicación de mensajería. Los investigadores lo llaman una extensión en lugar de un resultado medido. También es la única versión sin paso de instalación.

Correcciones, y una que no existe.

Dos de los cinco ya muestran cómo es el derecho. MobA transmite capturas de pantalla a través de salida ejecutiva y nunca tiene un archivo del lado del dispositivo para ejecutar. Open-AutoGLM pasa argumentos como listas en lugar de concatenar cadenas, y es el único de los cinco inmune a la inyección de comandos del host.

Ningún proyecto acierta en ambos. Ninguna de las correcciones siguientes requiere tocar el modelo:

  • Soltar shell=Verdadero. Pase listas argv, para que los metacaracteres permanezcan literales.
  • Transmita capturas de pantalla en lugar de escribir y luego extraer. Sin archivo del lado del dispositivo, sin ventana TOCTOU.
  • Coloque un permiso a nivel de firma en la transmisión de entrada o utilice intenciones explícitas.
  • Diferencia la actividad en primer plano antes y después de cada acción y mantén una lista de paquetes permitidos por tarea.
  • Ejecute la mejora del contraste en las capturas de pantalla antes de que el modelo las vea. Parcial, no es una solución.

La defensa obvia es un mensaje de confirmación sobre acciones sensibles, y Open-AutoGLM incluye uno. Se activa cuando el modelo decide que una acción es sensible. Los ataques de percepción reescriben ese juicio, razón por la cual el artículo califica el aviso como insuficiente contra la inyección subliminal, la suplantación de la interfaz de usuario y la manipulación de capturas de pantalla.

Ciberseguridad

Contra la difusión y el rastreo de accesibilidad, no hace nada en absoluto, porque no hay ninguna acción para confirmarlo. El texto ya desapareció. En cuanto a la inyección de esquinas y recortes, los investigadores son contundentes: «no existe una solución basada en software sencilla y eficaz». Enmascarar esquinas es una solución para un problema de hardware.

No hay donde reportarlo

El silencio tiene una estructura detrás. Zhang dijo que el equipo recurrió a un correo electrónico privado porque los proyectos no tienen un canal dedicado para informar vulnerabilidades y The Hacker News no encontró ninguna política de seguridad publicada en ninguno de los cinco repositorios.

El documento agrega que Tencent y Alibaba fueron los primeros en contactarse, y que los proyectos de código abierto de grado de investigación se encuentran fuera del alcance habitual del Centro de Respuesta de Seguridad.

Compare eso con el de Microsoft Informe de mayo sobre el kernel semánticosu marco de agente, donde el mismo patrón de salida del modelo que llega a un shell produjo CVE-2026-25592, CVE-2026-26030 y una versión parcheada. La versión de una sola línea de Microsoft se transfiere aquí sin modificaciones: «su LLM no es un límite de seguridad».

La mitad superpuesta no es un terreno nuevo. Wu et al. impulsó la inyección rápida a través de ventanas superpuestas contra AppAgent y Mobile-Agent en mayo de 2025, y Ding et al. seguido en octubre con indicaciones que aparecen solo mientras un agente está mirando.

La sección de trabajo relacionado de este artículo no cita ninguno de los dos y omite por completo la literatura sobre seguridad de agentes móviles. Lo que agrega es el otro extremo de la cadena: fuera de la pantalla, a través del archivo, hasta el host.

Lo que deja la parte incómoda. Open-AutoGLM tiene más de 25.000 estrellas de GitHub y su LÉAME Lo guía para habilitar la depuración USB, cargar el teclado y entregarle sus entradas. Siga los documentos exactamente y habrá creado todas las condiciones previas que necesitan los ataques medidos, excepto la aplicación maliciosa en sí. La guía de configuración es el resto del modelo de amenazas.

El jefe de presupuesto de Trump, Russell Vought, está abierto a renovar el personal de CISA

El jefe de presupuesto de la administración Trump, Russell Vought, dijo a los legisladores el martes que está dispuesto a trabajar con el secretario del Departamento de Seguridad Nacional, Markwayne Mullin, para renovar el personal de la Agencia de Seguridad de Infraestructura y Ciberseguridad, luego de profundos recortes de personal y nuevas reducciones propuestas en el plan de presupuesto fiscal para 2027.

Mullin dijo la semana pasada en una audiencia del Subcomité de Asignaciones de Seguridad Nacional de la Cámara de Representantes que le gustaría contratar a 600 personas más en CISA, similar a los comentarios que hizo a principios de este mes en otra audiencia de la Cámara. El presidente Donald Trump ha recortado o perdido más de 1.000 de una agencia que contaba con alrededor de 3.400 al final de la administración Biden, recortes criticados por legisladores de ambos partidos.

En una audiencia del Subcomité de Asignaciones de Servicios Financieros y Gobierno General de la Cámara de Representantes el martes, el representante Mark Amodei, republicano por Nevada, preguntó a Vought sobre los comentarios de Mullin sobre CISA.

«No basta con encender un interruptor de luz y ahora tienes 600 personas en CISA. ¿Cuál es el plan para que CISA esté en pleno funcionamiento?» preguntó Amodei, quien preside el Subcomité de Seguridad Nacional del panel. «¿Cómo podemos asegurarnos de tener una fuerza CISA sólida, efectiva y rentable? Porque no creo que nadie piense que la tenemos ahora».

Vought, director de la Oficina de Gestión y Presupuesto, dijo que no ha recibido una solicitud formal de Mullin para aumentar el número de empleados de tiempo completo de CISA, pero sabe que la contratación no es instantánea.

“Él no estaba aquí cuando desarrollamos este presupuesto, así que si siente la necesidad de tener recursos adicionales, lo solucionaremos internamente y, en el momento adecuado, vendremos a informarle”, respondió a Amodei. «Creo que todavía está en el proceso de abrazar al departamento», dijo. Mullen se convirtió en secretario del DHS a finales de marzo.

“Esta es probablemente una de esas cosas, particularmente en el mundo cibernético, ahora tenemos un año y medio de una nueva administración”, continuó Vought, y se refirió a las quejas conservadoras sobre cómo CISA manejó la seguridad electoral y la desinformación bajo Biden. «Vimos que esta agencia tenía grandes preocupaciones durante nuestros cuatro años fuera del gobierno y con la nueva administración, creo que ahora es una agencia, o podría ser una agencia, que juega un papel muy valioso para la cartera del DHS».

Incorporar a cientos de nuevos miembros del personal de CISA podría resultar un desafío por razones que van más allá de los obstáculos burocráticos habituales y los procesos de autorización de seguridad que retrasan cualquier contratación federal en el espacio de seguridad nacional. Ex empleados de CISA y observadores de la agencia han dicho que la forma en que la administración Trump ha depurado al personal y tratado a los que se han quedado podría resultar un desincentivo adicional para futuras contrataciones.

El director interino de CISA, Nick Andersen, dijo recientemente que la agencia ha comenzado el proceso de contratación de nuevo personal de CISA y espera tener casi 200 ofertas de trabajo para finales de este mes.

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

GuardFall expone agentes de codificación de IA de código abierto a riesgos de inyección de shell de décadas de antigüedad – CYBERDEFENSA.MX

El control de seguridad que se supone debe impedir que un agente de codificación de IA ejecute un comando peligroso se puede pasar directamente utilizando un truco de shell que ha sido público durante décadas.

Nueva investigación de IA adversaque se denomina bypass caída de guardiadescubrió que funciona contra diez de los once agentes populares de codificación y uso de computadoras de código abierto que la empresa probó. Sólo uno, «Continuar», fue construido para defenderse de ello.

¿Por qué importa? Estos agentes ejecutan comandos de shell con acceso completo a su cuenta. Apunte uno a un repositorio o paquete de software con trampa explosiva, y una instrucción oculta puede ejecutar silenciosamente un comando que borra archivos o roba los secretos a los que puede acceder su cuenta, desde claves SSH y credenciales de la nube hasta cualquier cosa que se encuentre en su carpeta de inicio.

¿Cómo pasa la guardia?

La mayoría de estos agentes intentan mantenerse seguros comparando cada comando con una lista de bloqueo de patrones peligrosos antes de ejecutarlo. El defecto es que verifican el comando como texto sin formato, mientras que bash reescribe ese texto antes de ejecutarlo. El shell elimina las comillas y expande los atajos, por lo que el filtro y el shell terminan mirando dos cosas diferentes.

El ejemplo más sencillo: un filtro que vigila habitación no ve nada malo en r»m, porque para un comparador de texto esas son cadenas diferentes. Bash elimina las comillas vacías y ejecuta rm de todos modos.

Ciberseguridad

La misma idea funciona en otras formas: un comando oculto en base64 y canalizado a un shell, o herramientas ordinarias como find y dd se vuelven destructivas con la bandera correcta.

Los investigadores no llaman a esto un error sino «una convención peligrosa y una clase de problemas», razón por la cual agregar más patrones de lista de bloqueo no soluciona nada de esto. No existe un único CVE para rastrear o parchar.

Dos cosas tienen que alinearse para que un ataque aterrice, y ninguna es exótica.

  • Primero, la IA tiene que producir el comando malicioso. Generalmente se rechaza un contundente «ejecutar rm -rf», pero el mismo comando escondido dentro de un trabajo de apariencia normal, como un archivo de compilación o la respuesta de «documentación» de una herramienta, se emite como un paso de rutina.
  • En segundo lugar, el agente debe ejecutarse por sí solo, con un indicador de ejecución automática activado o su entorno de pruebas de contenedor desactivado, los cuales son rutinarios en las canalizaciones automatizadas. Las pruebas en vivo utilizaron Claude Sonnet 4.6.

Las otras diez herramientas dejaron la brecha abierta: opencode, Goose, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands, SWE-agent y el proyecto Hermes, donde surgió el error por primera vez y ahora documentado en el propio rastreador de problemas de Hermes.

Las herramientas de la encuesta de Adversa tenían en conjunto aproximadamente 548.000 estrellas de GitHub en mayo de 2026. Adversa demostró el ataque completo de extremo a extremo contra el binario de producción Plandex, y la misma forma funcionó contra otros ocho. Describe el trabajo como investigación de laboratorio; no se ha informado de explotación pública.

Continúe, el único agente que se resiste, se defiende leyendo el comando como lo hará bash antes de decidir: divide el comando en las mismas partes que lo haría el shell, verifica lo que realmente se ejecuta y mantiene una lista estricta de comandos destructivos que están bloqueados por completo.

Ciberseguridad

Esa protección se mantuvo contra cada carga útil en el modo de editor predeterminado de Continuar. Su modo de ejecución automática de línea de comandos es más débil: algunas cargas útiles se escaparon, aunque las más destructivas aún alcanzaron el bloque duro. Adversa considera que el diseño es portátil y dice que volver a implementarlo requiere aproximadamente un trabajo de dos días para un ingeniero experimentado.

Que hacer ahora

Ninguna de las soluciones rápidas es una respuesta completa, pero reducen su exposición hasta que se implemente la protección adecuada:

  • Ejecute agentes con $HOME apuntando a una carpeta desechable, de modo que secretos como ~/.ssh y ~/.aws estén fuera de su alcance.
  • Desactive los indicadores de ejecución automática como –auto-exec, –auto-run, –auto-test y permisos de omisión peligrosa a menos que el trabajo realmente no pueda pausarse para un humano.
  • No permita que los agentes ejecuten solicitudes de extracción desde bifurcaciones, el camino fácil desde el archivo de un atacante hasta sus secretos.
  • Trate los archivos de configuración enviados dentro de un repositorio, como .aider.conf.yml, como código que no es de confianza; uno malicioso puede desencadenar el ataque en la primera edición aceptada.

GuardFall aterriza en medio de una serie de hallazgos similares este año. El propio adversario ConfianzaCaída presione Claude Code, Cursor, Gemini CLI y Copilot CLI, y un separado omisión de regla de denegación Pulsa Claude Code.

Ataques como AutoJack y Agentjacking convirtieron contenido envenenado en comandos que un agente ejecuta con los privilegios de su propietario. El hilo común es simple: el texto que no es de confianza sigue llegando a un shell real antes de que el guardia entienda qué se ejecutará realmente bash.

F5 parchea dos fallas críticas de código abierto de NGINX que permiten la ejecución remota de código – CYBERDEFENSA.MX

F5 ha publicado actualizaciones de seguridad para abordar dos fallas de seguridad críticas en NGINX Open Source que podrían explotarse para lograr la ejecución de código en los sistemas afectados.

Las vulnerabilidades se enumeran a continuación:

  • CVE-2026-42530 (Puntuación CVSS v4: 9.2): una vulnerabilidad de uso después de la liberación en el módulo ngx_http_v3_module que podría ser activada por un atacante remoto no autenticado cuando NGINX Open Source está configurado para usar el módulo HTTP/3 QUIC para reabrir una secuencia de codificador QPACK mediante una sesión HTTP/3 especialmente diseñada y ejecutar código en sistemas con la aleatorización del diseño del espacio de direcciones (ASLR) deshabilitada o cuando el atacante puede omitir ASLR.
  • CVE-2026-42055 (Puntuación CVSS v4: 9.2): una vulnerabilidad de desbordamiento de búfer basada en montón en los módulos ngx_http_proxy_v2_module y ngx_http_grpc_module que podría ser activada por un atacante remoto no autenticado cuando las directivas proxy_http_version to 2 o grpc_pass se usan para representar el tráfico HTTP/2, la directiva ignore_invalid_headers está desactivada y la El tamaño de la directiva large_client_header_buffers es superior a 2 MB y ejecuta código en sistemas con la aleatorización del diseño del espacio de direcciones (ASLR) deshabilitada o cuando el atacante puede eludir ASLR.
Ciberseguridad

Ambas deficiencias se han solucionado en las siguientes versiones:

  • CVE-2026-42530


    • Código abierto NGINX 1.31.0 – 1.31.1 (corregido en 1.31.2)
    • NGINX Gateway Fabric 2.0.0 – 2.6.3 (corregido en 2.6.4)
    • Estructura de puerta de enlace NGINX 1.3.0 – 1.6.2
    • Administrador de instancias NGINX 2.17.0 – 2.22.0
    • Controlador de ingreso NGINX 5.0.0 – 5.5.0
    • Controlador de ingreso NGINX 4.0.0 – 4.0.1
    • Controlador de ingreso NGINX 3.5.0 – 3.7.2
  • CVE-2026-42055


    • NGINX Plus 37.0.0 – 37.0.1 (Fijo en 37.0.2.1)
    • NGINX Plus R33 – R36 (Fijo en R36 P6)
    • Código abierto NGINX 1.31.1 (corregido en 1.31.2)
    • Código abierto NGINX 1.30.0 – 1.30.2 (corregido en 1.30.3)
    • Administrador de instancias NGINX 2.17.0 – 2.22.0
    • F5 WAF para NGINX 5.9.0 – 5.13.1
    • Aplicación NGINX Protege WAF 5.2.0 – 5.8.0
    • Aplicación NGINX Protege WAF 4.10.0 – 4.16.0
    • F5 DoS para NGINX 4.9.0
    • Aplicación NGINX Protege DoS 4.3.0 – 4.7.0
    • NGINX Gateway Fabric 2.0.0 – 2.6.3 (corregido en 2.6.4)
    • Estructura de puerta de enlace NGINX 1.3.0 – 1.6.2
    • Controlador de ingreso NGINX 5.0.0 – 5.5.0
    • Controlador de ingreso NGINX 4.0.0 – 4.0.1
    • Controlador de ingreso NGINX 3.5.0 – 3.7.2

Como mitigaciones, F5 ha descrito las siguientes acciones:

  • CVE-2026-42530: deshabilitar HTTP/3
  • CVE-2026-42055: elimine la directiva ignore_invalid_headers off de la configuración o reduzca el tamaño de la directiva large_client_header_buffers por debajo de 2 MB

Aunque F5 no menciona las vulnerabilidades que se están explotando en la naturaleza, los malos actores han explotado repetidamente las fallas de seguridad en los productos de F5.

Tan recientemente como el mes pasado, otro defecto de seguridad crítico en NGINX Plus y NGINX Open Source (CVE-2026-42945, puntuación CVSS: 9.2), también llamado NGINX Rift, fue explotado activamente pocos días después de la divulgación pública.

Los investigadores construyen un gusano de IA autorreplicante que funciona completamente en modelos locales de peso abierto – CYBERDEFENSA.MX

Investigadores de la Universidad de Toronto han construido y probado una prueba de concepto de gusano informático impulsado por IA que utiliza un modelo de lenguaje grande y abierto alojado localmente para razonar su camino a través de una red, generar estrategias de ataque personalizadas para cada objetivo que encuentre y replicarse, todo sin intervención humana y sin tocar un servicio comercial de IA.

La preimpresión, publicado en arXiv el 2 de junio y actualmente bajo revisión por pares, muestra por qué el parche CVE único falla cuando el malware puede inspeccionar servicios expuestos, leer nuevos avisos y generar una nueva ruta de ataque en tiempo de ejecución.

En 15 ejecuciones aisladas en una red de 33 hosts deliberadamente vulnerable, el gusano identificó un promedio de 31,3 vulnerabilidades y obtuvo acceso elevado en 23,1 hosts, aproximadamente tres cuartas partes de los hosts a los que atacaba activamente. Luego se replicó de forma autónoma en 20,4 de esos hosts, o el 62% de la red completa, durante siete días, sin conocimiento previo de la topología de la red ni intervención humana.

Los gusanos tradicionales se envían con una carga útil de exploit fija elegida en el momento de su creación. Parche esos errores específicos y el gusano dejará de propagarse.

Este gusano hace algo diferente: utiliza un LLM de peso abierto que se ejecuta en una sola GPU para generar una lógica de ataque en tiempo de ejecución, adaptada a lo que encuentre en el siguiente objetivo. Sin cadena de exploits precodificada. No hay dependencia de OpenAI, Anthropic o cualquier otra API que una plataforma pueda revocar o limitar.

Lo que realmente hizo el gusano

Dirigido por el profesor asociado Nicolas Papernot, el Laboratorio CleverHans El equipo abarca la Universidad de Toronto, el Vector Institute, la Universidad de Cambridge y ServiceNow. Realizaron 15 experimentos independientes en una red aislada de 33 hosts («FakeCorp») que abarca Ubuntu, Debian, Rocky Linux, Alpine, Windows Server 2008 R2, 2019 y 2022, y dispositivos IoT.

Cada host tenía al menos una vulnerabilidad del mundo real. Cinco de las 33 máquinas tenían GPU. En los principales experimentos de propagación, el gusano utilizó un grupo de inferencia de GPU compartido para simular la computación adquirida de las máquinas víctimas. El equipo probó por separado la replicación completa de nivel de GPU, en la que el gusano coloca una instancia LLM local en un host de GPU comprometido; que tuvo éxito en el 68,8% de los intentos.

Ciberseguridad

En el diseño por niveles, los hosts infectados con capacidad de GPU sirven como nodos de razonamiento distribuidos que proporcionan inferencias para dispositivos de computación inferior en la red que no pueden ejecutar el modelo por sí mismos.

En las 15 ejecuciones, el gusano obtuvo acceso elevado en 23,1 hosts y lanzó con éxito una réplica en el 88% de ellos. Alcanzó hasta siete generaciones de autorreplicación, con una media de 5,1. La configuración era intencionalmente vulnerable: el documento dice que la prueba mide el razonamiento autónomo a través de fallas individuales realistas, no propagadas a través de una red de producción mayoritariamente reforzada bajo defensa activa de endpoint.

Los exploits en una sola ejecución incluyeron un SambaCry encadenado y una escalada de privilegios cron de root grabables, Dirty Pipe, PrintNightmare, Drupalgeddon 2, Exim RCE, inyección ciega de SQL, derivación de JWT, escape de Redis y más, no porque estuvieran preprogramados, sino porque el agente razonó hasta llegar a ellos a partir de lo que encontró en cada host.

La Figura 2 del artículo mapea el árbol de propagación radial completo en una ejecución, mostrando de seis a siete generaciones de distribución en hosts Linux, Windows e IoT. Los intentos de explotación individuales tuvieron éxito aproximadamente el 44% de las veces. La mayoría de las fallas se debieron a una sintaxis de carga útil mal formada, no a una lógica defectuosa. Los exploits de aplicaciones web y la escalada de privilegios de Windows fueron más difíciles que los exploits locales y de servicios de Linux, un límite de capacidad que el documento trata como una limitación del modelo actual, no como una defensa estructural.

El problema de la ventana de parcheo

El gusano superó su propio límite de entrenamiento al ingerir texto de aviso público en tiempo de ejecución, explotando con éxito hosts de prueba configurados con tres vulnerabilidades reveladas después de que se entrenó el modelo:

Contra esos tres huéspedes, el gusano logró arraigarse en 41 de 67 intentos.

CVE-2026-39987 se reveló el 8 de abril de 2026. Sysdig observó explotación en honeypots 9 horas y 41 minutos después de eso, y documentó por separado una intrusión en el mundo real en la que un atacante utilizó un agente LLM para actividad posterior a la explotación después de comprometer una instancia pública de Marimo. La misma brecha de parche de siempre, ahora con un agente leyendo el aviso y probándolo a escala.

El paralelo relevante con WannaCry es la brecha del parche, no el radio de explosión. EternalBlue había sido parcheado durante meses antes de que apareciera WannaCry. El documento plantea el mismo punto bajo una restricción diferente: un gusano adaptativo puede seguir probando nuevas rutas mientras los defensores todavía están validando las soluciones.

Coste marginal cero, sin interruptor de apagado central

Hay dos cosas que hacen que sea más difícil de contener que un gusano tradicional.

  • En primer lugar, el costo pasa del acceso alquilado a la API a cualquier cálculo que el gusano pueda capturar. Una vez que existe una infraestructura de víctima con capacidad de GPU, el atacante ya no paga por intento.
  • En segundo lugar, debido a que todo se ejecuta en modelos abiertos sin dependencia del proveedor, los controles del lado del proveedor pasan por alto el problema central. Rechazos de servicio, limitación de tarifas, suspensión de cuenta: nada de esto aplica. No hay ninguna clave API para revocar. La contención tiene que ocurrir en la capa de red y de host.

Los investigadores también observaron que el gusano reescribía su propio código en varias ocasiones para eludir los controles de seguridad locales en el entorno de prueba, comportamiento que nunca codificaron.

La versión actual se construyó deliberadamente sin características sigilosas: sin cifrado, sin código polimórfico, sin mecanismos de persistencia, sin cobertura de pistas. Una variante maliciosa con persistencia, cargas útiles cifradas, enmascaramiento de procesos y limpieza de registros les daría a los defensores menos señales fáciles que deja este prototipo.

donde encaja esto

Esta no es la primera investigación sobre gusanos impulsada por IA. Morris II (Cohen et al., 2025) mostró un aviso adversario autorreplicante que se propagaba entre los asistentes de correo electrónico de IA a través de generación con recuperación aumentada y propagación dentro de la capa de aplicación de IA, no a través de la infraestructura del host.

En marzo de 2026, gusano garra demostró ataques autorreplicantes en ecosistemas de agentes LLM, secuestrando configuraciones persistentes y propagándose a agentes pares. El gusano de Toronto es diferente: el LLM no es el objeto atacado. Es el motor de ataque que se utiliza para comprometer la infraestructura de red ordinaria.

Las operaciones en el mundo real ya están poniendo a prueba los mismos límites. Anthropic dijo en noviembre de 2025 que interrumpió una gran campaña de espionaje orquestada por IA atribuida con gran confianza a GTG-1002, un grupo patrocinado por el estado chino. Claude Code manejó entre el 80 y el 90 % de la operación, incluido el reconocimiento, el desarrollo de exploits, la recolección de credenciales, el movimiento lateral y la exfiltración, y los humanos intervinieron en algunos puntos de decisión.

Ciberseguridad

Threat Intelligence Group de Google informó de un cambio relacionado en mayo de 2026: lo que evaluó con gran confianza era el primer exploit de día cero desarrollado con asistencia de IA, encontrado en el script de un grupo criminal antes de un evento de explotación masiva planeado, junto con familias de malware que generan sus propios comandos en tiempo de ejecución en lugar de depender de una lógica codificada. El trabajo de Toronto es la versión de laboratorio de esa dirección impulsada hacia la propagación de gusanos a nivel de huésped.

La dirección es bastante clara: menos incitaciones, más delegación y más intrusión entregada al modelo.

¿Qué deberían hacer ahora los defensores?

Las señales de comportamiento que produce este prototipo dan a los defensores algo concreto que buscar, porque la versión actual no intenta esconderse.

  • Segmentar agresivamente las máquinas con capacidad de GPU. El diseño del gusano dirige la inferencia LLM a través de cualquier host GPU comprometido al que pueda llegar. En una red plana, un servidor de aprendizaje profundo comprometido se convierte en un centro de razonamiento para cada dispositivo infectado en la misma subred. Segmente la infraestructura de GPU y aplique controles de confianza cero para evitar el acceso lateral hacia y desde esos hosts.
  • Trate los avisos publicados como objetivos de armamento a corto plazo. Para los CVE conectados a Internet, la ventana de explotación ya se mide en horas para algunas vulnerabilidades. Verifique la explotabilidad rápidamente, parchee primero la exposición a Internet y utilice controles de compensación cuando la implementación no pueda realizarse antes del siguiente ciclo comercial.
  • Rote las credenciales expuestas en cualquier host comprometido o sospechoso de manera creíble. El gusano demostró la reutilización sistemática de credenciales como vía de propagación. Las credenciales recopiladas se mueven lateralmente más rápido que la mayoría de los ciclos de detección.
  • Supervise las señales de comportamiento específicas del agente. La actividad de puerto no estándar, la inyección automatizada de clave pública SSH y los grupos de inferencia LLM que aparecen en puntos finales inesperados son los artefactos observables que deja este prototipo. Son el punto de partida de la lógica de detección.

En las pruebas, esa combinación produjo raíz en nuevas vulnerabilidades en 41 de 67 intentos y replicación al 62% de la red en siete días sin más intervención humana. Una vez que existe un punto de apoyo de GPU dentro de una red plana, el costo de mapear y explotar hosts adicionales se reduce a cualquier cómputo que el gusano pueda capturar, mientras que los avisos públicos se convierten en guías inmediatas.

La implementación no se hace pública. La Universidad de Toronto está estableciendo un proceso de investigación para que investigadores defensivos calificados soliciten acceso.

Los sitios falsos que imitan herramientas de código abierto ocupan un lugar destacado en Google para distribuir malware a través de TDS

Los investigadores de ciberseguridad han señalado una operación a gran escala que se hace pasar por proyectos de código abierto y de software gratuito para canalizar a usuarios desprevenidos a través de un sistema de distribución de tráfico (TDS) y entregar familias de malware como Remus Stealer, AnimateClipper y el marco SessionGate.

«Los sitios están bien diseñados y a menudo parecen portales de proyectos legítimos a primera vista, a veces haciendo referencia a recursos reales», dijo el investigador de seguridad de Check Point, Alexey Bukhteyev. dicho en un desglose de la campaña. «El engaño no está sólo en el contenido de la página, sino en lo que sucede cuando un usuario interactúa».

«Estas páginas cargan una capa de preparación de JavaScript alojada en CloudFront que convierte un clic en un botón/enlace de ‘descarga’ en una transferencia a un Sistema de Distribución de Tráfico (TDS). El TDS aplica una restricción estricta: estado de primera visita, confirmación de clic obligatoria, lógica anti-bot/anti-análisis, filtrado de VPN/centro de datos y limitación de frecuencia».

Se sospecha que la operación está diseñada para la adquisición y monetización de tráfico, mientras conduce a usuarios selectos a la infraestructura de entrega de malware. Algunos de los sitios identificados imitan herramientas confiables de seguridad e ingeniería inversa, como Ghidra, dnSpy y SpiderFoot.

Ciberseguridad

Las cadenas de ataques se dirigen específicamente a los usuarios que buscan este tipo de herramientas en motores de búsqueda como Google, lo que hace que los sitios falsos aparezcan en la parte superior de los resultados de búsqueda. Una de las primeras versiones de la campaña fue documentado por Fullstory en noviembre de 2025. La evidencia indica que la actividad ha estado en curso desde septiembre de 2025.

«Estos dominios se centran en obtener clasificaciones favorables en los motores de búsqueda aprovechando el nombre, la marca y la popularidad de los sitios web y proyectos originales», señaló en ese momento la empresa con sede en Atlanta. «Muchos sitios se encuentran en los primeros puestos de Google para el término de búsqueda relevante, a menudo eclipsando el sitio web del proyecto real. Esto hace que su visibilidad sea una ventaja y puede maximizar los enlaces y el contenido».

Aunque no había indicios de que alguno de estos dominios se utilizara para actividades maliciosas, aparte de generar contenido para generar tráfico y permitir a terceros anunciar sus propios sitios, los últimos hallazgos de Check Point muestran que los scripts TDS se incorporaron poco después y la infraestructura se reutilizó para la distribución de malware a partir de enero de 2026.

Al hacer clic en el botón «Descargar», se inicia una cadena de redireccionamiento TDS que resulta en la implementación de malware. Uno de los aspectos más llamativos es que al pasar el cursor sobre el botón se revela la URL legítima desde donde se puede descargar la herramienta, otorgando así al sitio una apariencia de legitimidad.

Las cadenas de redireccionamiento también están diseñadas de manera que los intentos repetidos de ingresar desde la misma dirección IP resulten en la descarga de software benigno, como el navegador Opera o extensiones de navegador innecesarias. Algunas de las cargas útiles distribuidas a través de este TDS se enumeran a continuación:

  • Puerta de sesiónun cargador ofuscado de múltiples etapas previamente desconocido que se utiliza para entregar aplicaciones potencialmente no deseadas (PUA) al mismo tiempo que incorpora amplios mecanismos anti-análisis para eliminar las zonas de pruebas al pasar a una experiencia de instalación benigna.
  • Remus ladrónun nuevo ladrón de información que se ofrece bajo un modelo de malware como servicio (MaaS), puede robar datos de más de 20 navegadores, incluidos cientos de extensiones y aplicaciones de navegador, como billeteras de criptomonedas, herramientas de autenticación de dos factores y administradores de contraseñas. Se cree que Remus es una variante de Lumma Stealer.
  • AnimarClipperun cortapelos de criptomonedas que puede sustituir direcciones de billetera copiadas en el portapapeles y secuestrar transacciones en más de 20 ecosistemas blockchain. Se entrega mediante un señuelo ClickFix.

Un análisis de la telemetría de VirusTotal ha revelado aproximadamente entre 2000 y 3500 envíos de muestras asociadas con la familia SessionGate hasta la fecha. La gran mayoría de las presentaciones provienen de Turquía, Polonia, Brasil, Alemania, Francia, Rusia y el Reino Unido.

Ciberseguridad

El objetivo final de la secuencia de infección SessionGate es eliminar una carga útil que sea única por cliente y se entregue solo después de atravesar la ruta de redireccionamiento de un extremo a otro. La cadena de entrega de múltiples etapas, combinada con una lógica de validación extensa y activación del lado TDS, está diseñada para resistir el análisis y hacer que la recuperación de la carga útil sea una tarea desafiante para los analistas.

La carga útil final de la DLL es responsable de comunicarse con un servidor externo, recuperar una configuración cifrada del servidor, extraer la URL de descarga de la configuración y descargar y ejecutar silenciosamente el malware de la siguiente etapa a través de «cmd.exe».

«Los sitios de entrada imitan portales legítimos de proyectos de código abierto, conservan enlaces reales de GitHub para pasar verificaciones visuales rápidas y luego utilizan la interceptación de clics para enrutar el primer clic de descarga a una pila TDS cerrada», dijo Bukhteyev.

«El objetivo principal más plausible es la adquisición de tráfico y la monetización. Sin embargo, al incorporar una capa TDS cerrada y canalizar el tráfico de búsqueda en ella, los operadores se convierten en parte de una cadena de distribución cuyos consumidores posteriores pueden incluir distribuidores de malware. El mismo canal de tráfico que impulsa la monetización gris también puede enrutar selectivamente a usuarios reales a cargas útiles maliciosas».

CrowdStrike interrumpe la botnet Glassworm que se aprovechaba de la cadena de suministro de código abierto

CrowdStrike tiene desmanteló la botnet Glassworm en una operación con la ayuda de Google y Shadowserver, que despojó a los operadores del acceso a la infraestructura que ayudó a los actores de amenazas a infectar cientos de piezas de software de código abierto con malware desde principios de 2025, dijo la compañía el martes.

El esfuerzo coordinado implicó la eliminación simultánea de cuatro servidores controlados por atacantes que fueron diseñados para ocultar las operaciones de la botnet y permanecer resistentes a las interrupciones.

CrowdStrike y sus socios derribaron la infraestructura, cortaron el acceso a los servicios más críticos de la botnet, impidieron el impulso de la operación y desaceleraron la capacidad de los atacantes para escalar, dijo a CyberScoop Adam Meyers, vicepresidente senior de operaciones contra adversarios de CrowdStrike.

«El objetivo más amplio es una presión sostenida que obligue al adversario a gastar tiempo, recursos y energía operativa en reconstituir la infraestructura en lugar de atacar a las víctimas», añadió Meyers. «Al exponer el oficio y compartir inteligencia, los defensores pueden fortalecer los entornos de desarrollo, los canales de CI/CD y las cadenas de suministro de software contra actividades similares. Eso aumenta el costo operativo para el adversario y da a los defensores una ventaja».

Glassworm se ha dirigido a desarrolladores de software para acceder a repositorios de código fuente, plataformas en la nube, procesos de integración y entrega y registros de paquetes de código abierto para introducir malware en la cadena de suministro y desencadenar compromisos posteriores.

El grupo de amenazas detrás de la botnet, que probablemente tiene su sede en Rusia, según CrowdStrike, introdujo malware en extensiones VSCode, paquetes npm y Python y más de 300 repositorios de GitHub, dijeron los investigadores.

Glassworm afectó los sistemas Windows, macOS y Linux con robo de datos y credenciales, y una herramienta de acceso remoto llamada GlasswormRAT.

«Lo que destacó de Glassworm fue la sofisticación operativa en torno a la propagación y la automatización», dijo Meyers. «Esto no fue simplemente un compromiso de romper y apoderarse de un repositorio de paquetes. La operación fue diseñada para moverse a través de flujos de trabajo de desarrolladores confiables de una manera que podría expandir el alcance muy rápidamente si no se controla».

La botnet se basó en cuatro canales en capas que CrowdStrike interrumpió, incluida la cadena de bloques Solana, la red peer-to-peer de BitTorrent, Google Calendar y servidores privados virtuales alojados por proveedores comerciales.

«Como parte de nuestros esfuerzos de disrupción, estamos trabajando con socios para causar más dolor a los atacantes, especialmente cuando los vemos abusando de nuestros productos o atacando a nuestros usuarios», dijo John Hultquist, analista jefe de Google Threat Intelligence Group, en un publicar en X.

Las contramedidas destruyeron “el tejido conectivo de la operación para crear un dolor operativo en cascada”, dijo Meyers. «Esto obliga al adversario a reconstruir, al tiempo que expone el comercio».

CrowdStrike dijo que la eliminación demuestra cómo la industria de la seguridad puede frustrar eficazmente las amenazas a la cadena de suministro al interrumpir de manera proactiva la infraestructura precisa que utilizan los atacantes sin esperar largos procesos judiciales.

«Cuando los actores de amenazas operan desde jurisdicciones donde la cooperación policial es limitada o inexistente, la disrupción se convierte en una de las herramientas más eficaces disponibles. Si no se pueden poner esposas al operador, hay que centrarse en desmantelar la infraestructura, las relaciones de confianza y las dependencias operativas», añadió Meyers.

La empresa de seguridad compartió indicadores de compromiso para ayudar a las organizaciones a buscar posibles infecciones en sus entornos y pidió a otros proveedores, agencias de aplicación de la ley, operadores de plataformas y el ecosistema de código abierto que reúnan la misma determinación para responder a las amenazas en la cadena de suministro de software.

«Cuanto más visibilidad y alineación se cree en todo el ecosistema, más difícil será para el actor mantener silenciosamente la operación», dijo Meyers. «Es posible que no se elimine por completo al actor de la amenaza, pero se puede reducir absolutamente la eficacia, limitar el alcance y aumentar el costo de hacer negocios».

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

Código de cifrado resistente a cuánticos de código abierto de Apple

Apple ha lanzado un código criptográfico resistente a los cuánticos y las herramientas de verificación matemática que desarrolló para demostrar la exactitud del código, poniéndolos a disposición del público para su revisión independiente y su uso más amplio en toda la industria.

la liberación Incluye implementaciones de dos algoritmos de seguridad cuántica, ML-KEM y ML-DSA, junto con las bibliotecas y herramientas de verificación formal que Apple creó para validar su precisión. La compañía también publicó documentación detallada de su metodología de verificación, que describe como el logro de los resultados de corrección más sólidos conocidos para cualquier implementación de producción ampliamente implementada de estos algoritmos.

Los algoritmos de seguridad cuántica están integrados en núcleocriptola biblioteca criptográfica de Apple utilizada en todos sus sistemas operativos. La biblioteca maneja cifrado, descifrado, hash y firmas digitales en más de 2.500 millones de dispositivos activos. Apple comenzó a implementar cifrado resistente a los cuánticos en iMessage en 2024 y ha ampliado la tecnología a servicios VPN y protocolos de red TLS.

Una de las herramientas lanzadas es el traductor Cryptol-to-Isabelle de la compañía, que convierte modelos criptográficos entre lenguajes formales, junto con las bibliotecas de soporte necesarias para reproducir los resultados. La verificación formal utiliza pruebas matemáticas para demostrar que el código funciona correctamente para todas las entradas posibles. Apple tradujo su código al criptolun lenguaje formal desarrollado por Galois, luego en Isabelasistente de pruebas de la Universidad de Cambridge y de la Universidad Técnica de Munich, para demostrar que ambas cumplían con los estándares oficiales. Apple ha utilizado Isabelle anteriormente para verificar componentes criptográficos de hardware.

El proceso de verificación descubrió errores que las pruebas convencionales habrían pasado por alto. Los investigadores encontraron un paso computacional faltante en el código ML-DSA que habría roto silenciosamente las firmas digitales. Si este error hubiera llegado a producción, los mensajes en iMessage podrían haber aparecido autenticados cuando en realidad no lo estaban, dejando a los usuarios sin saber que sus comunicaciones carecían de la seguridad adecuada.

Incluso con estas herramientas, Apple reconoció que todavía depende de las pruebas criptográficas convencionales y que se necesita una evaluación para garantizarlo. La verificación formal puede detectar errores que las pruebas tradicionales simplemente no pueden encontrar. Las pruebas funcionan probando muchos escenarios, pero con un código criptográfico complejo, hay demasiadas entradas posibles para realizar pruebas exhaustivas. Los errores sutiles pueden ocultarse en los espacios entre los casos de prueba y nunca generar una advertencia. La verificación formal, por el contrario, utiliza las matemáticas para demostrar la corrección de todas las entradas posibles a la vez.

Sin embargo, el equipo de Apple escribe que no pudo verificar formalmente cada aspecto de su código con las herramientas disponibles, por lo que combinaron enfoques: verificación formal de la corrección matemática básica, pruebas convencionales para aspectos que los métodos formales no podían cubrir y evaluación cuidadosa de cómo funcionan todas las piezas juntas. Apple sostiene que este enfoque híbrido proporciona la seguridad más sólida para el software criptográfico crítico.

«Basándonos en nuestro trabajo hasta la fecha, creemos que la mayor garantía posible proviene de combinar la verificación formal con métodos convencionales y evaluar críticamente los resultados de un extremo a otro», se lee en la publicación del blog.

Además, el blog afirma que Apple seleccionó ML-KEM y ML-DSA entre varios algoritmos estandarizados resistentes a lo cuántico porque cumplían mejor con los requisitos de seguridad, rendimiento y parámetros compactos de la empresa. Los algoritmos abordan la amenaza que plantean las futuras computadoras cuánticas, que podrían potencialmente romper los métodos de cifrado que actualmente protegen las comunicaciones digitales.

Se puede encontrar más información en corecrypto de Apple. página de GitHub.

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

El jefe de CISA se preocupa por las vulnerabilidades del código abierto y las mejoras de seguridad retrasadas

Asegurar parte de la tecnología de código abierto que sirve como columna vertebral de toda la infraestructura digital moderna requerirá algunas “decisiones difíciles” en medio de una ola de ataques de malware, dijo el jueves el líder de la Agencia de Seguridad de Infraestructura y Ciberseguridad.

«La comunidad de código abierto es una que me preocupa especialmente cuando empezamos a pensar en una rápida escalada del descubrimiento de vulnerabilidades», dijo el director interino Nick Andersen, haciendo referencia una caricatura sobre cómo las tecnologías clave que sustentan Internet a menudo son mantenidas por una sola persona.

En un ataque reciente, un pirata informático secuestró la cuenta de un único responsable de un proyecto de código abierto para publicar actualizaciones maliciosas para axios, popular entre los desarrolladores de software, lo que aumentó el potencial de ataques que podrían extenderse más ampliamente. TeamPCP, un presunto grupo de piratería norcoreano, ha estado en una ola de ataques de código abierto.

«Aquí hay una tremenda oportunidad para rediseñar áreas… para hacer inversiones en áreas donde sabemos que nos han faltado, y simplemente forzar que se tomen algunas decisiones de seguridad difíciles… donde la gente pensaba que su perfil de riesgo era diferente de lo que es», dijo Andersen. «Vemos la escalada en términos de velocidad, escala y velocidad del descubrimiento de vulnerabilidades hasta el uso de armas y la explotación».

CISA ha estado trabajando con la industria y otros «para modificar nuestro enfoque de gestión de vulnerabilidades, modificar nuestro enfoque de divulgación coordinada de vulnerabilidades, modificar nuestro enfoque de remediación, con el entendimiento explícito de que simplemente no podremos seguir utilizando los mecanismos tradicionales», dijo Andersen, hablando en el Foro Nacional de Innovación Cibernética en Washington, DC.

El gobierno y el sector privado pueden trabajar juntos para identificar las mayores amenazas y luego brindarles el nivel adecuado de atención, dijo. Por parte del gobierno federal, eso significa trabajar para tener una imagen completa del grado de dependencia de las tecnologías de código abierto.

En general, Estados Unidos ha pospuesto demasiadas mejoras de seguridad necesarias, afirmó Andersen.

“Ya sea que se mire al sector privado o a nuestros gobiernos y las redes y sistemas del sector público que apoyamos, existe una enorme cantidad de deuda técnica”, dijo. No hemos realizado la inversión necesaria para poder asegurarnos fácilmente en el futuro”.

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.