Informe de respuesta de seguridad: Vulnerabilidad de inyección SQL

Resumen de la vulnerabilidad

‍

Tipo de vulnerabilidad: Inyección SQL
Fecha de notificación: 10 de marzo de 2025
Estado: Resuelta y corregida
Método de divulgación: Divulgación responsable por parte de Searchlight Cyber/Asset Note

‍

Versiones que contienen la resolución

Estable
2.174.94 (o cualquier versión que comience por 2.174 y termine con un número mayor que 94; por ejemplo, 2.174.103)
Candidata
2.184.23 (o cualquier versión que comience por 2.184 y termine con un número mayor que 23; por ejemplo, 2.184.35)
Beta
2.186.2 (o cualquier versión que comience por 2 y vaya seguida de un número mayor que 186 —por ejemplo, 2.187.1)

‍

Análisis del alcance y de las causas fundamentales

La vulnerabilidad permitía la inyección de SQL en un punto final sin autenticación mediante una carga útil especialmente diseñada. Se ha llevado a cabo un análisis completo de las causas, que ha permitido determinar que la vulnerabilidad se introdujo en la versión 2.11.13, publicada el 12 de junio de 2020. A pesar de haberse sometido a múltiples pruebas de penetración internas y realizadas por terceros, el problema persistió sin ser detectado debido a la complejidad de la carga útil necesaria. Esto redujo significativamente la posibilidad de que se produjera un ataque o se viesen comprometidos los datos.

Cabe señalar que esta vulnerabilidad se introdujo en 2020 y que, desde entonces, nuestras prácticas internas de desarrollo han mejorado considerablemente. Además, en el marco de la investigación no se han detectado más vulnerabilidades de este tipo.

‍

Exposición de datos e impacto

Se llevó a cabo una investigación de los registros de Azure Application Insights y AWS WAF correspondientes a los clientes de servicios en la nube o alojados. A raíz de esta revisión, no se identificó ninguna filtración de datos de los clientes . El análisis sugiere que la explotación requeriría un alto grado de especificidad, lo que limita la probabilidad de que se produzca un abuso generalizado con éxito.

‍

Calendario de detección y remediación

• Fecha de lanzamiento: 12 de junio de 2020 (v2.11.13)

• Fecha de notificación: 10 de marzo de 2025

• Parche implementado: el mismo día para todos los clientes de alojamiento (10 de marzo de 2025)

• Tiempo de respuesta: Implementación inmediata del parche tras recibir la notificación

Searchlight Cyber/Asset Note publicó sus conclusiones antes de lo previsto, lo que dejó a algunos clientes con instalaciones locales expuestos durante un breve periodo de tiempo.

Hemos colaborado con varios de estos clientes en investigaciones destinadas a encontrar pruebas de que se haya producido una intrusión o un ataque, pero hasta ahora no hemos encontrado ninguna.

‍

Frecuencia y cobertura

Cada año llevamos a cabo pruebas completas de autenticación y de penetración de la API a través de una empresa de seguridad externa acreditada por CREST, con el fin de garantizar evaluaciones independientes y de alta calidad. Además de estas revisiones externas, se realizan pruebas de penetración internas antes de cada lanzamiento estable trimestral, lo que nos permite identificar y subsanar de forma proactiva las posibles vulnerabilidades dentro de nuestro ciclo de desarrollo.

‍

Metodología de las pruebas

Nuestro proceso de pruebas de penetración incluye tanto pruebas con autenticación como sin ella, con el fin de garantizar una cobertura exhaustiva en todos los niveles de acceso. Estas evaluaciones las llevan a cabo una combinación de equipos de seguridad internos y especialistas externos, lo que permite obtener una valoración completa de nuestros sistemas desde múltiples perspectivas.

‍

Última evaluación de seguridad (prueba de penetración)

El 10 de enero de 2025 se llevó a cabo una prueba de penetración exhaustiva. El resumen ejecutivo del informe está disponible y puede facilitarse previa solicitud, con el fin de garantizar una mayor transparencia.

‍

Normas de programación y formación de desarrolladores

Todos los desarrolladores de Halo reciben formación sobre normas de programación segura y siguen las mejores prácticas reconocidas en el sector, incluidas las establecidas por OWASP. Esta formación se actualiza periódicamente para garantizar que se adapta a las últimas amenazas y técnicas de mitigación.

‍

Revisión de código y automatización

Todos los cambios en el código se someten a un riguroso proceso de aprobación de varias etapas que incluye la revisión por parte de un miembro sénior del equipo de seguridad, encargado específicamente de evaluar los posibles riesgos de seguridad. Además, utilizamos herramientas de pruebas estáticas de seguridad de aplicaciones (SAST) a lo largo de todo el proceso de desarrollo, lo que permite la detección temprana de vulnerabilidades y fomenta prácticas de programación seguras desde el principio.

‍

Gestión de la superficie de ataque

Aunque no es posible reducir el número de puntos finales de la API debido a requisitos funcionales esenciales —como la necesidad de aceptar respuestas de webhooks—, seguimos centrados en mantener y reforzar continuamente nuestro nivel general de seguridad. Ya hemos llevado a cabo evaluaciones rigurosas de los puntos de conexión no autenticados como parte de nuestras prácticas habituales de seguridad, por lo que, a pesar de la presencia de múltiples puntos de conexión no autenticados, la revisión reciente no identificó ninguna vulnerabilidad adicional. Estos puntos de conexión se evalúan y supervisan minuciosamente, y solo se utilizan cuando es absolutamente necesario para minimizar el riesgo.

‍

Segmentación de infraestructuras

En nuestros entornos alojados, se aplica la separación funcional entre los componentes clave —incluidos la API, la autenticación y los servicios de integración— para reducir el riesgo de movimiento lateral en caso de que se produzca una brecha de seguridad. Además, las bases de datos y los servidores de bases de datos están aislados de las capas de aplicación, y todos los datos cifrados solo son descifrados por la API y los servicios de autenticación, lo que garantiza una separación sólida entre el almacenamiento de datos y los mecanismos de acceso.

‍

Validación de la eficacia

Para reforzar nuestro nivel general de seguridad, estamos recurriendo a varias empresas de seguridad externas para que proporcionen una supervisión adicional y una validación independiente de nuestros sistemas. Paralelamente, estamos ampliando y mejorando nuestros controles de seguridad internos para garantizar una mayor cobertura, un análisis más exhaustivo y una mejora continua en todas las fases de desarrollo e implementación.

‍

Comunicación sobre seguridad

Reconocemos que algunos clientes se enteraron de esta vulnerabilidad a través de una publicación de investigación sobre seguridad realizada por un tercero, antes de recibir una comunicación directa de Halo. Esto se debió, en parte, al momento inesperado en que se publicó el informe externo, lo cual ocurrió mientras aún estábamos prestando apoyo activo a los clientes con instalaciones locales en su proceso de actualización.

Somos conscientes de la importancia de una comunicación proactiva y oportuna, por lo que hemos tomado medidas para mejorar nuestros procedimientos internos. De ahora en adelante, nos aseguraremos de que todos los clientes de nuestros servicios alojados sean informados de inmediato una vez que se haya aplicado un parche, independientemente del estado de las implementaciones en las instalaciones.

‍