lunes, 2 de noviembre de 202621°General Pico · 12° / 26°Dólar Oficial $1.560Dólar Blue $1.565Dólar MEP $1.575Dólar Tarjeta $2.028
VicOne halla 28 vulnerabilidades zero-day en menos de dos días en herramientas para robots
La firma VicOne detectó 28 fallas sin parche con ayuda de inteligencia artificial en software usado para entrenar, simular y operar robots. Los equipos deben evaluar cómo podrían afectar la seguridad de sus sistemas.
Redacción PicoTecno
3 min de lectura
(The Robot Report)
Según informó The Robot Report, la empresa VicOne identificó un primer conjunto de 28 vulnerabilidades zero-day en menos de dos días, usando investigación asistida por inteligencia artificial. Las fallas afectan software y herramientas del ecosistema de la llamada IA física, que son sistemas de inteligencia artificial vinculados a máquinas que actúan en el mundo real. Entre los proyectos mencionados figuran algunos desarrollados o mantenidos por Google, NVIDIA y Meta.
Una vulnerabilidad zero-day es una falla de seguridad que todavía no era conocida y para la que no existe una solución disponible. Por ahora, la fuente indica que las 28 fueron clasificadas como zero-day tras una validación inicial, aunque el número podría cambiar después de revisiones de los fabricantes y de las autoridades de vulnerabilidades. Además, algunas todavía no tienen un número de seguimiento CVE, el identificador estándar que se asigna a cada falla de seguridad publicada.
Muchas de estas herramientas sirven para entrenar, simular, probar y operar robots. Si tienen debilidades, podrían alterar los modelos que construyen los equipos, los resultados de las pruebas en los que confían y las instrucciones que reciben los robots.
Dónde se ubican los riesgos en el ciclo de vida del robot
De acuerdo con el informe, los hallazgos se distribuyen en tres etapas: desarrollo y entrenamiento, simulación y validación, y despliegue y operación en tiempo real. Según una figura incluida en la investigación, el 75 % de los casos involucra herramientas de desarrollo, entrenamiento, simulación o validación, lo que implica que los riesgos pueden aparecer antes de que el robot salga a producción.
Un ejemplo planteado en la nota es el de un equipo que descarga un modelo preentrenado para adaptarlo a su robot. Si ese archivo fuera malicioso, un atacante podría acceder al sistema de entrenamiento y modificar los datos o el modelo. El resultado podría ser un comportamiento que parece normal en las pruebas habituales, pero que responde mal ante determinados objetos o comandos una vez desplegado.
En la etapa de simulación, un entorno o un modelo de robot comprometido podría permitir alterar lecturas de sensores o resultados de pruebas. Así, un robot podría aprobar evaluaciones que deberían haber detectado conductas peligrosas, y el equipo lo habilitaría para uso real con evidencia engañosa. En la etapa de operación, la fuente señala que podrían modificarse archivos que influyen en la planificación de movimientos o enviarse datos de mapas que hagan fallar el panel de monitoreo, además de poner en riesgo las instrucciones enviadas desde una computadora de operación remota.
El informe aclara que estas son consecuencias potenciales y no resultados demostrados en todos los casos. Su alcance dependerá del acceso del atacante, del diseño del sistema y de si existen otras protecciones que impidan que los cambios lleguen al comportamiento físico del robot. Como ejemplo concreto, los investigadores de VicOne mostraron en una demostración una falla que impedía que funcionara el comando de parada remota de un robot, lo que muestra la importancia de comprobar que las salvaguardas sigan funcionando cuando el software que las sostiene está comprometido.
La nota también destaca que un parche publicado no alcanza por sí solo. Los equipos deben identificar los sistemas afectados, verificar la compatibilidad y confirmar que la actualización mantiene el comportamiento esperado. Una prueba anterior exitosa sigue siendo útil, pero una falla nueva puede revelar condiciones que nunca se evaluaron. Para responder, el informe propone tres preguntas: dónde se usa el software afectado, qué podría cambiar la falla y cómo verificar que la protección funciona. Si no es posible actualizar de inmediato, se pueden aplicar medidas temporales, como restringir el acceso al servicio vulnerable.
