La seguridad no comienza con la divulgación de CVE

Déjame contarte una historia Hay una versión ordenada, casi académica de cómo se supone que funciona la seguridad del software. Aparece en conferencias, documentos de cumplimiento y en los alegres diagramas vistos en diapositivas de marketing. Un investigador encuentra un bug, silenciosamente (y profesionalmente) lo informa arriba, arriba lo patches, se le asigna un CVE, los mantenedores de abajo sacan la corrección, los escáneres lo notan, los defensores lo patchan, y el mundo permanece en su mayoría bien. Si eso fuera realmente cómo funcionaban las cosas, no estaría aquí escribiendo sobre las correcciones, los parches silenciosos o los problemas de seguridad que existen en un lugar y desaparecen en otro. Y todo el mundo necesita saber. perturbado Lo que aprenderás en este artículo Inversión de la línea de tiempo de seguridad: cómo la divulgación de CVE no es el verdadero comienzo de la línea de tiempo de seguridad. Resultados de seguridad: Por qué las decisiones de mantenimiento de rutina, no la velocidad de reacción o las herramientas, determinan los resultados de seguridad. Indicadores defectuosos: Por qué las puntuaciones de CVE, los escáneres y los plazos de cumplimiento no son sistemas de alerta temprana eficaces. Distorsión de la vulnerabilidad: Cómo los componentes incorporados, forjados y de fin de vida obscuran la visibilidad en vulnerabilidades y responsabilidad. Cambios necesarios: Los cambios en la gobernanza y el ciclo de vida son necesarios para evitar que se demore estructuralmente a las vulnerabilidades "silenciosas". En febrero de 2025, Apache Tomcat envió un conjunto de Llegaron sin urgencia, sin comentarios, y sin el tipo de ruido que puede acompañar a incidentes de seguridad significativos. rutina Para la mayoría de los equipos, no había ninguna razón inmediata para tratar estas versiones de manera diferente a otras actualizaciones de mantenimiento. Nada parecía roto. Nada parecía comprometido. No había identificador de vulnerabilidad para reaccionar. Unas semanas más tarde, esos mismos lanzamientos se convirtieron en el centro de una emergencia de seguridad. En el momento en que CVE-2025-24813 se hizo público en marzo, el camino del código vulnerable ya había sido identificado, corregido y enviado a través de las sucursales Tomcat respaldadas. La solución existía antes de que el problema tuviera un nombre. Para todos los demás, vino como una desagradable sorpresa: una puntuación CVSS de 9,8 es una gran manera de comenzar tu día. Siéntate libre de consultar los detalles de la CVE aquí Veremos el contenido más adelante, ya que lo que se graba y quién lo graba son parte de esta historia.Los detalles técnicos de la CVE son en su mayoría irrelevantes. Modalidad: tiene que ser permitido. https://nvd.nist.gov/vuln/detail/CVE-2025-24813 defecto https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Esta secuencia de eventos nos ayudará a comprender cómo pueden evolucionar los CVEs y cómo eso puede afectar a los consumidores. Inversión de la línea de tiempo de seguridad Esta inversión es fácil de perder si solo miras las fechas de divulgación.Las líneas de tiempo de seguridad generalmente se dicen como si empezaran cuando se publica un CVE.En realidad, comienzan antes.Cuando se informa del problema o cuando los mantenedores cambian el código. Cuando un cohete en la plataforma de lanzamiento comienza a contar hacia abajo, vemos que los motores empiezan antes de que el cohete abandone el suelo. Esa es la especie de patrón que vemos con CVEs. En este caso, el equipo de seguridad de Tomcat siguió un patrón que es completamente normal para la infraestructura de código abierto de larga duración. Llegó un informe privado. El problema fue investigado. Se desarrolló y envió una solución. Silenciosamente, y todo antes de que el ‘rocket’ saliera de la plataforma. La intención no era el secreto sino la contención: el objetivo es reducir la ventana durante la cual los defensores no tienen una respuesta viable. Hábito vs. Hype Ese enfoque funciona bien para las organizaciones que tratan los lanzamientos de puntos como algo a aplicar. de rutina. Aquellos equipos actualizaron sin saber por qué, y en el momento en que la vulnerabilidad fue discutida públicamente, ya estaban protegidos. Para las organizaciones que dependen de la divulgación como el desencadenante para la acción, marzo se sintió como un día cero. La vulnerabilidad apareció completamente formada, completa con puntuaciones de severidad, reivindicaciones de explotación, etc. Desde el exterior, parecía que todos estaban enfrentando el mismo riesgo al mismo tiempo. Dos equipos podrían haber estado ejecutando versiones idénticas de Tomcat en enero y acabaron en posiciones muy diferentes a mediados de marzo. Uno fue aislado, el otro expuesto. Fue El hábito. La falsa suposición de alarmas fuertes Hay una suposición persistente en muchas organizaciones de ingeniería de que los problemas de seguridad serios se anunciarán lo suficientemente fuerte como para exigir la atención. Esa suposición es cada vez más poco fiable. En este caso, el indicador más crucial era indistinguible del mantenimiento rutinario. Una entrada de changelog. Un golpe de versión. Una liberación que no se sintió urgente porque nada había dicho aún a nadie que debería. Una vez que el CVE fue publicado, la narración habitual tomó el control. La vulnerabilidad adquirió un nombre, una puntuación y un público objetivo. Las discusiones sobre la gravedad, la explotabilidad y la configuración comenzaron de inmediato. Priorizar los cambios sobre las historias Es tentador ver esos lanzamientos de febrero como un momento afortunado. No lo fueron. Simplemente fueron el resultado de un proceso que prioriza la fijación de código sobre la gestión de la percepción. Estructurados para responder a historias en lugar de cambios, a declaraciones en lugar de difusiones. Inconscientemente Al momento en que el ecosistema más amplio comenzó a debatir las implicaciones de CVE-2025-24813, el resultado técnico ya había sido establecido.Algunos sistemas eran seguros, otros no eran, y la distinción no tenía nada que ver con la rapidez con la que alguien reaccionó en marzo. Cómo este CVE (y para ser honesto, la gran mayoría de todos los CVEs) se desplomó en todo el mundo fue una colisión de interpretaciones, evaluaciones y obligaciones Es ahí donde este estudio de caso se vuelve interesante y hace una muestra tan grande. Aquí está el calendario principal Los elementos críticos circulan alrededor de la información CVE y CPE de la NVD. . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Necesito subrayar que esto no tiene la intención de sugerir que algo irreversible ocurrió.Este es un ejemplo de cómo están las cosas. Necesito subrayar que esto no tiene la intención de sugerir que algo irreversible ocurrió.Este es un ejemplo de cómo están las cosas. 13 de enero de 2025. Vulnerabilidad Informada en privado El equipo de seguridad de Apache Tomcat recibe un informe privado de una vulnerabilidad que involucra solicitudes parciales de PUT de HTTP y el servlet de archivo predeterminado. 24 de enero de 2025: Fijación comprometida. El comité La solicitud de retiro asociada se llama “Enhance lifecycle of temporary files used by partial PUT” (Enhance el ciclo de vida de los archivos temporales utilizados por PUT parcial). https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 10 de febrero de 2025: Fix es lanzado en silencio. Apache silenciosamente lanza Tomcat 9.0.99, 10.1.35, y 11.0.3 con la corrección incluida. que es un mes antes de la divulgación pública. 10 de marzo de 2025: CVE-2025-24813 Publicado En la actualidad, la red de telecomunicaciones y servicios de telecomunicaciones se encuentra en el centro de la red de telecomunicaciones de Telecomunicaciones y Telecomunicaciones de la Comunidad de Madrid ( • Citas https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Este problema afecta a Apache Tomcat: de 11.0.0-M1 a 11.0.2, de 10.1.0-M1 a 10.1.34, de 9.0.0.M1 a 9.0.98 13-14 de marzo de 2025: Comienzan las explotaciones de PoC y los ataques activos Dentro de 30 horas de la divulgación, los exploits de prueba de concepto se publican públicamente. Los intentos de escaneo masivo y de explotación comienzan inmediatamente. Método de ataque: cargar la webshell de JSP a través de PUT parcial, desencadenar a través de la solicitud JSESSIONID elaborada. Sources: Sonatype Blog | CyRisk Analysis 17 de marzo de 2025: se añade un exploit POC al registro CVE de NVD https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 18 de marzo de 2025: se añade la primera información CPE al CVE El CPE Es la información mágica que hace que el CVE sea básicamente legible por máquina. Permite a los consumidores automatizados del CVE “saber” qué versiones del producto son vulnerables. https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe En este punto, el CPE simplemente coincide con la declaración de rango de versiones original que vio antes. 19-26 de marzo de 2025: Análisis de proveedores de seguridad publicado Rapid7, Akamai, Wiz y Sonatype publican análisis detallados. Rapid7 señala que "no hay necesidad de pánico" porque la explotación generalizada no fue confirmada y algunos de los prerequisitos declarados de Apache fueron sobreestimados. Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 1 de abril de 2025 :CISA se añade al catálogo KEV El CVE registra que CISA añade CVE-2025-24813 a su catálogo de vulnerabilidades explotadas conocidas, citando evidencia de explotación activa. a las agencias federales de EE.UU. se les ha dado un 22 de abril de 2025, fecha límite para el patch. Sources: Keysight Analysis | Amazon Linux Advisories A principios de abril de 2025: lanzamiento de patches de proveedores empresariales Red Hat, Amazon, SUSE, Atlassian y otros proveedores empresariales lanzan patches. La mayoría de ellos enfatizan que las configuraciones predeterminadas no son vulnerables ya que el servlet predeterminado es solo de lectura. Sources: Red Hat CVE | Amazon CVE 3 de julio de 2025: Unidad 42 reporta 125K+ intentos de ataque La Unidad 42 de Palo Alto informa de 125.856 intentos de explotación bloqueados solo en marzo de 2025.La mayoría del tráfico de explotación parece ser "oportunista" utilizando PoCs públicos por actores de baja sofisticación. Source: Unit 42 Report ¿Estamos hechos? Bueno, para algunos usuarios de Tomcat, aquellos en versiones 9, 10 o 11, todo está bien.Tienen una corrección, y mientras se actualicen, entonces son seguros. 7 de agosto de 2025 - CVE actualizado "Las versiones más antiguas de EOL también pueden verse afectadas". Debido a algunos lobbies liderados por HeroDevs, el equipo de Apache añadió una advertencia. Esto es importante. Esto sucede muy raramente, pero había ingenieros en la mezcla en Apache y en otros lugares que sentían que la advertencia era necesaria. 8 de agosto de 2025 - CVE Actualizado con más información sobre versiones EOL El CVE ahora afirma: “Las siguientes versiones eran EOL en el momento en que se creó el CVE, pero son Se sabe que está afectado: 8.5.0 a 8.5.100.” Ahora el CVE es oficialmente aplicable a otra versión del flujo de Tomcat. hoy Incluso hoy en día, este CVE no ha sido actualizado para incluir la información CPE que podría ayudar a un escáner a detectar un problema en la versión 8.5. Parte de eso se puede atribuir a la naturaleza del CVE. Ya que la vulnerabilidad sólo es posible si se cambia una configuración predeterminada. cambió a Verdadero = Verdadero Leer más = falso. Esto significa que, en teoría, la explotabilidad depende de que el usuario de Tomcat pueda hacer este cambio.Si Tomcat se incorpora de una manera que impida que esta configuración sea cambiada, entonces el producto “embedding” puede justificadamente afirmar que no son vulnerables.Pero el estándar seguro de una persona es el simple hack o bypass de otra persona. También hay muchas forcas y variantes comerciales de Apache Tomcat. Por ejemplo, es un componente de Spring Boot, y Broadcom Tanzu también lo incorpora. ¿Cuántos jarros de grasa hay allí donde se ha perdido la información del componente, o el proyecto POM ha sido actualizado desde el envío? Cómo se diluye el mensaje La verdad a menudo amarga es que el informe de CVE y la obtención de la conciencia adecuada a las personas adecuadas fallan. De hecho, cuanto más popular es un componente para forcar o embeder, más difícil puede ser llegar a aquellos que necesitan saber sobre él. A menudo, en el calor del momento, los proveedores subterráneos alcanzan el informe inicial de CVE pero no vuelven para obtener actualizaciones. La danza correctamente afirma que el CVE se aplica a Tanzu y le asigna su propio identificador, TNZ-2025-014. Alertan a sus usuarios de que el CVE es aplicable a las versiones 9,10 y 11, pero entonces, como siempre, se vuelve confuso. La suite Tanzu es sofisticada y compleja. De repente, el CVE, en lugar de ser un simple ' ', se convierte en una lista de maybes y falsos positivos. no sé si Tanzu tiene versiones con Tomcat 8 o anteriores - supongo que lo hacen. Dado que su asesoramiento es datado 2025-03-25, mucho antes de que el CVE tenía la versión adicional EOL info añadido, uno puede simpatizar con este error, incluso si podría ser una exposición importante para productos más viejos Tanzu. Página de soporte son-yo-expuesto o no Un escenario común En el momento en que CVE-2025-24813 adquirió un nombre, una puntuación y un ciclo de medios, el resultado ya había divergido. La reparación existía antes de la CVE. Algunos sistemas estaban protegidos antes de que nadie supiera por qué. Esa divergencia no surgió de la concienciación, de las herramientas o de cualquier inteligencia de amenazas.Vino del timing.Más precisamente, de una suposición de que la seguridad comienza cuando se declara una vulnerabilidad, en lugar de cuando el código cambia silenciosamente. Lo que siguió no fue un evento único, sino una cascada prolongada. El texto del CVE evolucionó. Los datos del CPE llegaron tarde e incompletamente. Las recomendaciones de los proveedores remodelaron el alcance. Los plazos de cumplimiento endurecieron verdades parciales en la política. Las actualizaciones sobre la exposición a EOL aparecieron meses más tarde, después de que ya se habían tomado muchas decisiones a continuación. Nada de esto era malicioso. Nada de eso era inusual. El ecosistema moderno de vulnerabilidad se comporta cuando trata la divulgación como un momento en lugar de un proceso. Cómo No ocurrió en marzo. ocurrió en enero, febrero, marzo, agosto y más allá. Dependiendo de dónde te sientas y de qué señales te fies.La incómoda realidad es que en el momento en que el ecosistema más amplio había terminado de debatir la gravedad y la explotabilidad, el resultado técnico ya había sido fijado. CVE-2025-24813 ¿Cómo deberías reaccionar? ¿Qué significa esto para usted y qué hacer a continuación Por mucho que no me guste el término “verdad incómoda”, es el que se utiliza más a menudo en estas circunstancias. la situación es todo lo que necesitamos para resolverla. Así que la "conclusión incómoda" de este estudio de caso no es que era inusual. es que nada sobre cómo se informó y gestionó fue Aceptar CVE-2025-24813 inusual en absoluto La vulnerabilidad no llegó con ningún fanfare. No se anunció como urgente. Se resolvió antes de que se llamara. Los sistemas que sobrevivieron lo hicieron no porque reaccionaran más rápido, sino porque ya habían decidido, mucho antes, cómo tratarían el cambio. Si su posición de seguridad depende de ¿Por qué una actualización importa antes de aplicarla, entonces ya está operando demasiado tarde? Conocer En los ecosistemas modernos, la explicación sigue a la acción, no al revés. ¿Qué significa esto en la práctica , la divulgación ya no es el comienzo de la línea de tiempo de seguridad. En el momento en que un CVE adquiere un nombre, una puntuación y finalmente un plazo de cumplimiento, el trabajo técnico decisivo a menudo ya ha ocurrido en otro lugar.Si su organización trata la divulgación como el desencadenante para el movimiento, usted está estructuralmente expuesto a correcciones silenciosas que nunca priorizará en el tiempo. First Los escáneres no te dan previsión; simplemente te dicen que estás demasiado tarde. Second Las bases de datos CVE, CPE y catálogos KEV son herramientas de coordinación. ayudan a los grandes ecosistemas a moverse juntos una vez que una narración se estabiliza. ni siquiera cuando salió silenciosamente.Tratarlos como sistemas de advertencia temprana crea puntos ciegos. En realidad , “seguro por defecto” no es una estrategia. Third Muchos equipos se reconfortaron en la idea de que esta vulnerabilidad requería una configuración no predeterminada.Esta distinción colapsó en el momento en que las distribuciones incorporadas, las forcas y las implementaciones de JAR de grasa entraron en el cuadro. Si no puede demostrar cómo se configura un componente en la producción, no puede confiar en las suposiciones de seguridad de arriba. El hábito derrota a los heroicos. La diferencia entre los sistemas protegidos y los expuestos en esta historia no era la herramienta, la inteligencia de amenazas o la velocidad de respuesta. Finally Lo que debes hacer a continuación No esperes a que el próximo CVE pruebe estas suposiciones, ya tienes suficiente información para actuar. Identificando las fuentes de sus decisiones de actualización. Start Si las actualizaciones se priorizan sólo después de que una vulnerabilidad sea nombrada, marcada o mandada, esto es un problema de gobernanza y control, no un problema técnico. Las decisiones se toman, no qué herramientas se consultan. Cuando Cómo tratar las liberaciones “silenciosas”. Examine Pregúntate qué lanzamientos de punto en tu entorno se aplicarían automáticamente, y cuáles serían pospuestos hasta que se justifique.Cada postergación que hagas es una apuesta de que la justificación llegará antes de que el exploit lo haga. responsabilidad por los componentes de fin de vida explícitamente. Map Si una dependencia ya no es respaldada por el Upstream, el riesgo ya no es abstracto o futurista.La responsabilidad de seguridad ya ha cambiado.Ahora se sienta con usted, con un vendedor a continuación, o con nadie.Y esa ambigüedad es en sí misma una forma de exposición. Debo ser explícito sobre mi propia posición aquí. Trabajo para una empresa Esto es una forma, a veces muy práctica, de recuperar el control cuando aparecen vulnerabilidades en el software antiguo. puede comprar espacio para respirar. puede estabilizar un sistema lo suficiente para tomar decisiones sensatas. (Los héroes Pero no es la única opción, ni un sustituto para entender cómo acabaste aquí. El soporte extendido es una red de seguridad, no una estrategia. Así son las actualizaciones aceleradas, los controles compensatorios, el aislamiento o el cambio arquitectónico. Todos ellos son respuestas válidas en diferentes contextos. El modo de fracaso real no es elegir ninguna respuesta. Drifting a un estado donde nadie es claramente responsable, y ninguna respuesta es realmente propiedad, es la elección equivocada. El fin de la vida no significa “inseguro por defecto”. Significa que la carga de la prueba se ha desplazado. Alguien ahora tiene que llevar activamente la responsabilidad de seguridad. Si no puede indicar quién es o explicar cómo se cumple esa responsabilidad, entonces el riesgo ya está presente, ya sea que un CVE tenga su atención o no. Tratar la seguridad como un ciclo de vida, no como un evento. Así lo hacen la mayoría de las vulnerabilidades reales.Si tus procesos solo se involucran en el momento de la divulgación, estás optimizando para las narraciones, para las historias, en lugar de los resultados. Finally CVE-2025-24813 La seguridad no comienza en el ascensor En el momento en que el recuento llega a cero, los motores ya están ardiendo durante mucho tiempo.La única pregunta es si te di cuenta, y si has construido tus sistemas para moverse antes de que alguien te diga por qué.