JetBrains, el fabricante de una plataforma de servidor de integración y entrega continua (CI/CD) llamada TeamCity, y la firma de seguridad cibernética Rapid7, están intercambiando golpes por el manejo de dos vulnerabilidades graves en el servicio mientras los clientes se apresuran a parchear ante una explotación confirmada. . Los dos problemas en cuestión se rastrean como CVE-2024-27198 y CVE-2024-27199. El primero es una falla de omisión de autenticación en el componente web de TeamCity a través de un problema de pase alternativo, con una puntuación base CVSS de 9,8, lo que significa que es un problema crítico. El segundo tiene el mismo efecto, pero tiene una puntuación base CVSS de 7,3. En la publicación del blog de Rapid7 que detalla los problemas, el investigador principal de Rapid7, Stephen Fewer, quien descubrió las vulnerabilidades, escribió: «Comprometer un servidor TeamCity permite a un atacante tener control total sobre todos los proyectos, compilaciones, agentes y artefactos de TeamCity y, como tal, es un vector adecuado para posicionar a un atacante para realizar un ataque a la cadena de suministro”. En el centro del desacuerdo se encuentra una diferencia en los enfoques para la divulgación y parcheo de vulnerabilidades. Las vulnerabilidades se revelaron a JetBrains a través de su política de divulgación coordinada el jueves 15 de febrero de 2024. JetBrains lo reconoció el lunes 19 de febrero y reprodujo los problemas el martes 20 de febrero después de que Rapid7 le proporcionara un análisis técnico. En la versión de la narrativa de Rapid7, JetBrains luego sugirió lanzar parches de forma privada antes de una divulgación pública. Respondió enfatizando la importancia de la divulgación coordinada y describió su postura contra el llamado parche silencioso. Luego, las cosas estuvieron tranquilas durante varios días hasta el viernes 1 de marzo, cuando Rapid7 volvió a JetBrains y reiteró una solicitud de más información sobre las versiones afectadas de TeamCity y las pautas de mitigación de los proveedores. Se le informó de los números CVE asignados, pero por lo demás se le dijo que el problema aún estaba bajo investigación. Luego, el lunes 4 de marzo, sin comunicación con Rapid7, JetBrains publicó un blog anunciando el lanzamiento de la nueva versión de TeamCity, que solucionó las vulnerabilidades. Rapid7 dijo que expresó su preocupación porque el parche se lanzó sin notificación ni coordinación y sin avisos publicados. Según su propia política de divulgación de vulnerabilidades, si Rapid7 se da cuenta de que se emitió un parche silencioso, “tratará de publicar” detalles de la vulnerabilidad dentro de las 24 horas, lo que ya ha hecho. Desde entonces, JetBrains publicó un blog sobre el tema y un aviso, y afirmó que los CVE se incluyeron en las notas de la versión de la nueva versión de TeamCity, pero no respondió directamente a las preocupaciones de Rapid7 sobre la divulgación no coordinada. En la versión de la historia de JetBrains, no cuestiona que propuso lo que Rapid7 llamaría un parche silencioso, pero sostuvo que este método de divulgación seguía su política de divulgación coordinada. Dijo que quería seguir este camino para permitir a los clientes tomar una decisión informada sobre el nivel de riesgo, darles tiempo para actualizar y evitar que atacantes menos hábiles exploten las fallas mientras tanto. JetBrains dijo que tomó la decisión de no hacer una divulgación coordinada después de enterarse de que esto significaría que Rapid7 publicaría detalles técnicos completos de las vulnerabilidades al mismo tiempo que caían los parches. “Para reiterar, nunca tuvimos la intención de publicar una solución en silencio sin hacer públicos todos los detalles. Como Autoridad de Numeración CVE (CNA), asignamos ID de CVE para ambos problemas un día después de recibir el informe”, escribió Daniel Gallo, ingeniero de soluciones de TeamCity en JetBrains. “Sugerimos revelar los detalles de las vulnerabilidades de la misma manera que hemos seguido en el pasado, con un retraso de tiempo entre la publicación de una solución y la divulgación completa, lo que permite a nuestros clientes actualizar sus instancias de TeamCity. «Esta sugerencia fue rechazada por el equipo de Rapid7, que publicó todos los detalles de las vulnerabilidades y cómo explotarlas unas horas después de haber publicado una solución para los clientes de TeamCity». Parches silenciosos: una mala idea El enfoque de divulgación coordinada adoptado por Rapid7 es ampliamente aceptado y completamente normal dentro del mundo de la seguridad cibernética, aunque JetBrains no ha declarado explícitamente por qué rechaza este enfoque, según escribió en 2022 el principal director de investigación de seguridad de Rapid7, Tod Beardsley. , ofreció una posible explicación cuando dijo que, tomado al pie de la letra, el parcheo silencioso podría parecer apropiado para algunos porque parece limitar el grupo de personas que entienden el problema y cómo aprovecharlo. Explicando por qué este no es el caso, Beardsley escribió: “Cuando una compañía de software lanza un parche… en algún momento tiene que modificar el código del software en ejecución, lo que significa que todo está disponible para cualquiera que tenga una instancia en ejecución del software parcheado. y sabe utilizar un depurador y un desensamblador. ¿Y quién utiliza los depuradores para inspeccionar los efectos de los parches? Explotan a los desarrolladores, casi exclusivamente”. Teniendo esto en cuenta, dijo Beardsley, los parches silenciosos de hecho limitan el conocimiento de la vulnerabilidad parcheada a los desarrolladores de exploits capacitados, es decir, los actores de amenazas, por lo que si bien es cierto que los parches silenciosos eliminan a los hackers ocasionales y poco calificados y a los script kiddies, también excluye a los buenos, los probadores de penetración legítimos, los desarrolladores de tecnologías defensivas, los respondedores de incidentes y toda la comunidad cibernética que podrían beneficiarse de poder comprender mejor el problema y comunicarlo de manera efectiva. “Lo más significativo es que está excluyendo a la audiencia más importante para su parche: los administradores y gerentes de TI habituales que necesitan ordenar el flujo entrante de parches en función de algunos criterios de riesgo y gravedad y solicitar tiempo de inactividad y programación de actualizaciones en función de ese criterio. No todas las vulnerabilidades son iguales y, si bien los protectores quieren solucionarlas todas, necesitan determinar cuáles aplicar hoy y cuáles pueden esperar hasta el próximo ciclo de mantenimiento”, escribió. Resumiendo el argumento de Rapid7, Beardsley dijo que los parches silenciosos comunican detalles de vulnerabilidad «exclusivamente» a los atacantes cibercriminales expertos y a los actores estatales que ya están apuntando al producto vulnerable. «Todo esto quiere decir que la aplicación de parches silenciosos equivale a una divulgación total a una audiencia muy pequeña que en su mayoría quiere perjudicarlo a usted y a sus usuarios», concluyó. En el caso de las nuevas vulnerabilidades de TeamCity, la importancia de la divulgación coordinada adquiere importancia adicional, dado que problemas anteriores en el servicio han sido fuertemente explotados nada menos que por APT29, también conocido como Cozy Bear, la unidad cibernética del servicio de inteligencia exterior ruso ( RVS). Para los usuarios locales de TeamCity atrapados en el fuego cruzado (las versiones en la nube están completamente parcheadas), la guía es simple; La divulgación fallida significa que se ha eliminado la capacidad de evaluar sus factores de riesgo y la única solución es aplicar el parche inmediatamente.

Source link