La política de divulgación de 90 días ha muerto

 (blog.himanshuanand.com)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • La divulgación responsable de 90 días perdió su efecto de protección porque los LLM aumentaron el número de descubridores y la velocidad de desarrollo de exploits
  • En 6 semanas, 11 personas reportaron el mismo bug crítico de validación de pagos, lo que dejó en evidencia una redescubierta simultánea
  • Un diff de parche de React se convirtió en un exploit funcional en solo 30 minutos con ayuda de IA
  • Copy Fail y Dirty Frag terminaron en PoC públicos y explotación real, lo que hizo colapsar el embargo
  • Los problemas críticos deben tratarse como P0 de inmediato, y los LLM deben integrarse en el pipeline de seguridad

Por qué se rompió el modelo de divulgación responsable de 90 días

  • El período de divulgación responsable de 90 días se diseñó bajo la premisa de un entorno donde los descubridores de bugs eran escasos y el desarrollo de exploits era lento
  • En los últimos 12 meses, las herramientas usadas por responsables de seguridad, atacantes e investigadores se volvieron más inteligentes a un ritmo similar, y se considera que los LLM redujeron casi a 0 el tiempo necesario para encontrar vulnerabilidades y desarrollar exploits
  • En el modelo estilo 2019, como el de Google Project Zero, se le daban 90 días al vendor, bajo estas suposiciones durante ese tiempo
    • casi nadie más encontraría el mismo bug
    • incluso si otra persona lo encontraba, le tomaría tiempo
    • el vendor tendría suficiente ventaja inicial para escribir el parche
    • después de hacerse público el parche, al atacante le tomaría días o semanas hacer ingeniería inversa y crear un exploit funcional
  • Todas esas suposiciones resultaron falsas, y la ventana de 90 días terminó convirtiéndose, en lugar de una protección para los usuarios, en una estructura que da 90 días de ventaja a quienes ya tienen el bug

Caso 1: 11 personas reportaron el mismo bug crítico en 6 semanas

  • A fines de abril se reportó un bug grave a una empresa, pero el equipo de triage respondió que el primer reporte había llegado en marzo y que ese era el reporte número 11
  • El bug consistía en que, después de comprar algo en un sitio web, un atacante podía reenviar al servidor una respuesta manipulada manualmente y, como no existía verificación de firma sobre esa respuesta, el servidor la aceptaba tal cual
    • Por ejemplo, se podía comprar un artículo de 5,000 dólares por 0 dólares o completar una compra sin realizar un pago real
  • El hecho de que 11 personas distintas encontraran el mismo bug crítico en unas 6 semanas muestra un patrón en el que cazadores asistidos por LLM convergen casi al mismo tiempo sobre la misma vulnerabilidad
  • Un conocido de BlueWater CTF ya había señalado meses antes que reporteros y workflows no relacionados estaban convergiendo sobre los mismos bugs con ayuda de LLM
  • El mismo fenómeno también se observó del lado de triage
    • @d0rsky escribió que, cuando se descubre una nueva vulnerabilidad, en pocos días llegan reportes duplicados con la misma causa raíz impulsados por prompts de LLM, habilidades y automatización
    • Si los investigadores pueden reproducir esto tan rápido, crece la preocupación de que los black hats puedan hacer lo mismo antes de que exista un parche
  • Si 10 personas lo reportaron, puede haber otras que no lo hicieron, y el mismo LLM no está disponible solo para investigadores bien intencionados
  • El crédito CVE y el bug bounty solo pueden dársele a 1 persona, así que las otras 9, o quienes nunca lo reportaron, no están atados al reloj de 90 días
  • En esta situación, la ventana de divulgación de 90 días no protege a los usuarios y solo les compra tiempo a quienes ya tienen el bug

Caso 2: del parche de React a un exploit funcional en 30 minutos

  • React corrigió varios problemas de seguridad y publicó una entrada de blog al respecto
  • Tomó 30 minutos leer el parche y crear un exploit funcional contra una app local de prueba
  • El problema público en cuestión era de denegación de servicio (DoS), y la IA se encargó de la mayor parte de entender el diff, identificar la ruta de código vulnerable y escribir el PoC
  • Antes, convertir un parche público en un exploit n-day funcional requería que una persona experta en ingeniería inversa dedicara días o semanas, y esa diferencia de tiempo era la red de seguridad para que los administradores pudieran actualizar
  • Ahora, los bugs simples pueden pasar a explotarse en minutos, y los complejos en cuestión de horas, sin que un reverser experto sea indispensable
  • Hay que asumir que en cuanto sale el parche también existe el exploit, y ya no tiene sentido posponer el despliegue hasta la siguiente ventana de mantenimiento

Caso 3: Copy Fail y Dirty Frag estallaron seguidos en el kernel de Linux

  • En las últimas 2 semanas aparecieron dos vulnerabilidades críticas consecutivas en el kernel de Linux, ambas con exploits públicos y con impacto en distribuciones importantes

  • Copy Fail

    • El 29 de abril, Xint Code publicó Copy Fail
    • Xint Code es el equipo detrás de Theori, presentado como un equipo con 9 victorias en DEF CON CTF
    • Copy Fail es CVE-2026-31431 y se describe como una falla lógica sencilla en el subsistema crypto del kernel
    • Se dice que es 100% confiable sin race conditions, y que con un script de Python de 732 bytes puede obtener privilegios root en cualquier distribución de Linux publicada desde 2017
    • Ubuntu, RHEL, Amazon Linux, SUSE y otras distribuciones importantes están afectadas
    • Se encontró usando IA para escanear automáticamente el subsistema crypto/ del kernel durante alrededor de 1 hora, y se afirma que la vulnerabilidad llevaba expuesta 9 años
    • El análisis técnico está en la publicación de Xint
    • El parche salió en el commit mainline a664bf3d603d, y también existía la mitigación de desactivar el módulo algif_aead
    • Después, se observó que atacantes iraníes habrían usado la vulnerabilidad para comprometer servidores Ubuntu y reutilizarlos como nodos de una campaña DDoS
    • Solo pasaron unos días entre el hallazgo con IA de una vulnerabilidad de elevación de privilegios en el kernel, la publicación del PoC y su weaponization por atacantes a nivel estatal

  • Dirty Frag

    • Aproximadamente una semana después, el 7 de mayo, Hyunwoo Kim(@v4bel) publicó Dirty Frag
    • Dirty Frag encadena CVE-2026-43284 y CVE-2026-43500
    • Encadena dos vulnerabilidades presentes en los módulos de networking IPSec ESP (esp4/esp6) y RxRPC del kernel
    • Pertenece a la misma familia de bugs que Copy Fail y Dirty Pipe, usando la misma técnica de corrupción de page-cache, aunque con una ruta de ataque distinta
    • Dirty Frag funciona incluso si se aplica la mitigación de Copy Fail
      • Aunque se ponga algif_aead en blacklist, Dirty Frag no usa ese módulo
    • Se afirma que puede escalar de manera determinista de un usuario sin privilegios a root, y que funciona en Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 y otras distribuciones importantes
    • Se puede compilar y ejecutar con un solo comando de una línea

  • El proceso de divulgación de Dirty Frag y el colapso del embargo

    • Hyunwoo Kim lo reportó el 29 y 30 de abril a [email protected] y envió públicamente el parche propuesto
    • El 7 de mayo coordinó con la lista de correo linux-distros y se acordó un embargo de 5 días
    • Ese mismo día, en cuestión de horas, un tercero no relacionado publicó información detallada de explotación sobre la vulnerabilidad de ESP y el embargo se rompió
    • Tras consultar con los mantenedores de las distribuciones, Hyunwoo publicó el análisis completo de Dirty Frag, el código del exploit y un PoC funcional
    • En ese momento, había 0 distribuciones de Linux con parche disponible
    • Hasta ahora, solo CVE-2026-43284, es decir, la parte de ESP, tiene fix mainline, mientras que CVE-2026-43500, es decir, el componente RxRPC, sigue sin parche upstream
    • Ubuntu, Red Hat, Tenable y otros publicaron sus propios avisos

  • Explotación real de Dirty Frag

    • El equipo de Microsoft Defender confirmó explotación real limitada dentro de las 24 horas posteriores a la publicación
    • Según el informe, los atacantes obtuvieron acceso por SSH, desplegaron binarios ELF, consiguieron privilegios root con su, modificaron configuraciones de autenticación, borraron archivos de sesión y realizaron movimiento lateral
    • CTS(@gf_256) lo resumió diciendo “responsible disclosure is dead🤦”

Lo que realmente murió

  • La ventana de divulgación de 90 días no es un problema que pueda arreglarse: es un modelo terminado
  • Este modelo encajaba en un mundo con pocos descubridores y desarrollo lento de exploits, pero los LLM hacen que haya más descubridores y que el desarrollo de exploits sea más rápido
  • Si 10 personas no relacionadas pueden encontrar el mismo bug en 6 semanas y la IA puede convertir un patch diff en un exploit funcional en 30 minutos, la ventana de 90 días ya no protege a nadie
  • Copy Fail pasó de un escaneo con IA a un PoC público y a la weaponization por atacantes estatales en solo días
  • Dirty Frag vio romperse su embargo en cuestión de horas por un tercero que encontró independientemente la misma familia de bugs
  • En un entorno donde la misma vulnerabilidad puede ser redescubierta de forma independiente y simultánea por múltiples investigadores y herramientas de IA, es difícil sostener la coordinación de divulgación
  • El ciclo mensual de parches también terminó
    • La ventana de 30 días entre vulnerabilidad y fix asumía que el atacante se movería más lento que el release train
    • Cuando Microsoft ve explotación real de Dirty Frag en 24 horas, la ventana mensual de mantenimiento deja de ser un margen de seguridad y se convierte en una ventana de ataque
  • También terminó la práctica de esperar el advisory
    • Mientras el defensor lee la descripción del CVE, el atacante está leyendo git log --diff-filter=M
    • El advisory es un producto downstream; el patch diff es la señal

Qué debe cambiar en la respuesta de la industria

  • La conclusión es que todos los problemas críticos de seguridad deben tratarse como P0 y corregirse de inmediato
  • Ya no basta con “dentro de 24 horas”, “en el próximo sprint” o “después de evaluar el impacto”; hay que detener lo que se está haciendo y arreglarlo ya
  • Hay razones válidas por las que el despliegue en producción es complejo y requiere gestión de cambios, pero el entorno de amenazas no espera esos procesos

  • Vendors

    • El tiempo empieza a correr desde el momento en que entra el reporte del bug crítico
    • No desde el final del triage ni desde que ingeniería se hace cargo, sino desde el instante en que llega el reporte
    • Si alguien lo reportó, hay que asumir que otras 10 personas ya lo tienen y que al menos 1 de ellas no es amistosa

  • Investigadores

    • No deben retener bugs críticos por mucho tiempo y deben empujar la ventana de divulgación más corta posible
    • Si un vendor no puede arreglarlo en 1 semana, eso ya no es un problema de divulgación sino un problema del vendor
    • La antigua cortesía de “dar tiempo” tenía sentido cuando uno era el único descubridor, pero ahora es muy probable que ya no lo sea

  • Gestión de vulnerabilidades

    • La gestión de vulnerabilidades debe ser en tiempo real
    • “escaneo semanal, triage en el sprint y parche en el ciclo” corresponde a una línea de tiempo donde el atacante ya se fue
    • El nuevo tiempo máximo de respuesta para problemas críticos ya no son días sino horas, y hasta eso puede ser demasiado lento

Por qué los blue teams deben meter LLM en el pipeline defensivo

  • Los atacantes ya integraron LLM en su pipeline de exploits, y la defensa debe moverse a la misma velocidad
  • Hay que integrarlos en el momento del push de código
    • En cada pull request, merge y deploy debe ejecutarse revisión de seguridad asistida por IA como parte del pipeline de CI
    • Debe correrse al momento del push, como un linter o un unit test, no como una auditoría trimestral ni una revisión posterior
    • Si hay una vulnerabilidad, debe detectarse antes de llegar a producción, y arreglarla en un PR review cuesta mucho menos que corregirla después de que salga un CVE
  • También hay que integrar LLM en el análisis de parches
    • Cuando una dependencia upstream publique un parche de seguridad, el pipeline debe traer automáticamente el diff, analizar los cambios, determinar si afectan al codebase propio y levantar alertas
    • No debe depender de que una persona lea listas de correo y abra un ticket en Jira; debe ocurrir automáticamente en minutos desde que el parche aparece en un repositorio público
    • Si Xint Code encontró Copy Fail con 1 hora de escaneo automático, también hay que escanear así las dependencias propias
  • También hay que usar LLM en el escaneo de dependencias
    • La supply chain es tan fuerte como su dependencia transitiva más débil
    • Un escáner de dependencias basado en IA puede rastrear el impacto de una vulnerabilidad en el árbol de dependencias, marcar las versiones afectadas y hasta sugerir rutas de upgrade
    • Debe ejecutarse de forma continua, no semanal
  • Hay que probar los parches con IA antes de liberarlos
    • Si, como en el caso de React, un LLM puede convertir un parche en un exploit en 30 minutos, los defensores deben validar primero con esas mismas herramientas antes de publicar el parche
    • Hay que verificar que el parche realmente resuelva el problema y no introduzca uno nuevo
    • Debe aprovecharse también para generar pruebas de regresión y revisar si el mismo patrón aparece en otras partes del codebase
  • La ventana entre “existe una vulnerabilidad” y “se explota una vulnerabilidad” se está acercando a 0, y la defensa también debe automatizarse a la misma velocidad que el ataque
  • Habrá más zero-days explotados en entornos reales y más rápido, por las mismas herramientas, la menor barrera de entrada, el aumento de descubridores y la reducción de tiempos
  • Los equipos que sobrevivan a esta transición serán los que conviertan la IA en un componente de primera clase del pipeline de seguridad antes de que se los impongan por la fuerza

Conclusión

  • La nueva normalidad es la del administrador de sistemas que lee el advisory de Dirty Frag y se encuentra con que no hay parche, el exploit ya es público, Microsoft ya observó explotación real, la mitigación consiste en desactivar módulos IPSec y aun así tiene que tocar 400 servidores
  • La política de divulgación de 90 días, el ciclo mensual de parches y la suposición de que existe tiempo entre divulgación y explotación ya murieron
  • Lo que todavía queda es la capacidad de moverse rápido, automatizar con fuerza y tratar los bugs críticos como verdaderas emergencias
  • La misma ola de IA que rompió el modelo anterior también hace posible el nuevo: parches rápidos, escaneo automático, inteligencia de amenazas en tiempo real y revisión de código asistida por IA
  • Las herramientas ya existen; la clave es si los defensores las usarán antes que los atacantes, y por ahora los atacantes llevan la delantera

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Lobste.rs

  • A regañadientes, no me queda más que estar de acuerdo. En nuestra empresa también investigamos este tema, y el tiempo del parche al exploit es prácticamente inmediato

  • La política de divulgación responsable siempre fue una ficción que la gente fingía creer por cortesía mutua. Desde el principio se siguió más por inercia social, y las herramientas de descubrimiento de vulnerabilidades basadas en LLM solo dejaron eso al descubierto

  • Se siente bastante irónico que este mismo texto también huela a que lo escribió un LLM

    • Tiene sentido. Si tienes una idea original, tienes que publicarla antes de que alguien más lo haga. El pensamiento crítico y la autorreflexión murieron, y si no lo subes a un blog dentro de los 39 minutos de habérsete ocurrido, alguien más se te adelanta :P
    • A mí no me lo parece. Este estilo de escritura ya existía desde mucho antes en los textos técnicos previos a los LLM, y los principales LLM normalmente escriben de una forma algo distinta a la de este texto
    • Se lee como publicidad que busca meter miedo
    • Para bien o para mal, parece que ahora simplemente así es como van las cosas

  • Tal vez lo que murió fue la era de los programas en C artesanales y de nicho usados en situaciones de misión crítica