Puede que las vulnerabilidades de ClickShare se hayan parcheado, pero ocultan un problema mucho mayor

Una versión de este artículo apareció en DevOps.com. Se ha actualizado para su distribución aquí e incluye enlaces interactivos a desafíos de vulnerabilidad.

Creo que todos recordamos alguna ocasión reciente en la que, durante una reunión o conferencia, alguien tuvo problemas con la tecnología de presentación. Ocurre tan a menudo que casi se espera una experiencia torpe, al menos al principio. Por tanto, no sorprende que la aplicación de ClickShare fuera popular de inmediato entre los usuarios finales. Para ellos, no hay nada más sencillo que usar la aplicación ClickShare para enviar una presentación desde su portátil, tableta o teléfono inteligente a una pantalla grande o al proyector de una sala de conferencias. Barco, el proveedor belga de tecnología de proyección e imagen digital, diseñó su plataforma de automatización para que funcionara así, y las grandes empresas adoptaron el concepto. FutureSource Consulting sitúa la cuota de mercado de Barco en tecnología para conferencias en un 29%, con integración en el 40% de todas las empresas de la lista Fortune 1,000.

Cuando los investigadores de F-Secure revelaron en diciembre que la plataforma de automatización, aparentemente inofensiva, estaba plagada de vulnerabilidades de seguridad, la noticia conmocionó a la comunidad empresarial. Las fallas de seguridad descubiertas son de naturaleza crítica y podrían permitir potencialmente una gran variedad de actividades maliciosas.

Los investigadores demostraron cómo las vulnerabilidades podrían permitir a usuarios remotos espiar presentaciones activas, crear puertas traseras en redes seguras o incluso configurar un servidor de distribución de software espía que infectaría a cada usuario que se conectara a un dispositivo Barco. De repente, las empresas se enfrentaron a la posibilidad de tener graves problemas de seguridad instalados directamente en las salas de conferencias y oficinas de toda su organización. Y debido a la naturaleza de las vulnerabilidades, un solo dispositivo comprometido podría facilitar una brecha en toda la red.

"Un atacante que logre comprometer una unidad obtiene la capacidad de descifrar y producir imágenes cifradas válidas para cualquier unidad, ya sea dentro de una misma familia o entre familias distintas", escribieron los responsables de F-Secure en su informe. "Además, dicho atacante podría obtener acceso a datos confidenciales almacenados, como la PSK de Wi-Fi configurada y los certificados".

En su favor, Barco ha sido extremadamente proactivo a la hora de publicar parches y correcciones para las vulnerabilidades encontradas en sus productos. El proveedor de seguridad Tenable publicó recientemente un informe que muestra 15 vulnerabilidades en ocho herramientas de presentación, incluida Barco. A fecha de febrero, solo Barco ha trabajado activamente en la implementación de correcciones.

Aunque algunas de las vulnerabilidades de Barco requieren cambios de hardware (y estos serán una pesadilla de implementar, si es que una empresa llega a tomar medidas de este calibre para asegurarlos), muchas de ellas pueden corregirse con parches de software. Esto ofrece a la mayoría de los usuarios empresariales un plan aparentemente bueno para solucionar sus problemas inmediatos, pero no están ni mucho menos fuera de peligro. Los problemas con Barco son solo la punta del iceberg cuando se trata de lidiar con vulnerabilidades en productos de hardware y software bien conocidos.

La raíz del problema

Ahora que los problemas inmediatos se han resuelto, debemos preguntarnos cómo dispositivos con graves fallas de seguridad terminaron en miles de salas de conferencias en todo el mundo, o por qué fueron diseñados y programados tan deficientemente desde el principio. No es que el equipo de F-Secure estuviera descubriendo vulnerabilidades de día cero o desconocidas. Diez de las fallas descubiertas en los productos de Barco estaban asociadas con vulnerabilidades comunes bien conocidas, como los ataques de inyección de código. La mayoría ya contaba con identificaciones de Vulnerabilidades y Exposiciones Comunes (CVE).

Entonces, ¿cómo es que CVEs de hace décadas terminaron codificados, o incluso integrados, en herramientas de presentación modernas? La única respuesta posible es que los desarrolladores no los conocían o que la seguridad no fue una prioridad durante el diseño de los dispositivos Barco. Lamentablemente, esta es una situación común y, desde luego, no exclusiva de los equipos de Barco.

El mejor momento para corregir una vulnerabilidad es durante el desarrollo de una aplicación, mucho antes de que llegue a los usuarios. El peor (y más costoso) es después de que un producto se haya implementado o después de que haya sido explotado por atacantes. Esta puede ser una lección dura, y una que Barco seguramente aprenderá a medida que su cuota de mercado, antes inexpugnable, se vea afectada tras este fiasco de seguridad.

Trasladar las correcciones de seguridad al proceso de desarrollo no es sencillo, pero es necesario en el mundo actual, donde incluso dispositivos aparentemente simples, como las herramientas de presentación, son sorprendentemente complejos y están conectados a todo lo demás. En este entorno, la seguridad debe convertirse en una mejor práctica organizacional. No importa si una empresa programa aplicaciones para redes sociales o fabrica tostadoras inteligentes, la seguridad debe considerarse en cada faceta de la organización.

Priorizar las mejores prácticas de seguridad y convertirlas en una responsabilidad compartida es el objetivo del movimiento DevSecOps, donde los equipos de desarrollo, seguridad y operaciones trabajan juntos para programar e implementar software y productos seguros. Requiere un cambio de cultura tanto como cualquier otra cosa. La nueva mentalidad debe ser que implementar un producto funcional con vulnerabilidades de seguridad es un fracaso tan grande como crear uno que no pueda realizar su función principal.

En un entorno DevSecOps saludable, cualquiera que trabaje con software debe ser consciente de la seguridad, y los desarrolladores deben recibir formación relevante y frecuente para evitar introducir errores desastrosos en su trabajo. Si los equipos que trabajaban para Barco hubieran visto la seguridad como una responsabilidad compartida, no hay forma de que una colección tan grande de vulnerabilidades, incluyendo CVEs de hace décadas, hubiera llegado a sus herramientas de presentación.

El camino seguro a seguir

Nadie quiere ser el próximo Barco, teniendo que explicar por qué se implementaron fallas de seguridad bien conocidas a través de sus dispositivos en miles de redes empresariales de todo el mundo. Para evitar ese destino, las empresas que desarrollan software o hardware inteligente deben priorizar de inmediato la seguridad como una responsabilidad compartida y una mejor práctica organizacional. Crear un programa DevSecOps saludable llevará tiempo y probablemente también requiera un cambio de cultura, pero los resultados valdrán mucho más que el esfuerzo. Un DevSecOps robusto puede acabar con las vulnerabilidades mucho antes de que causen problemas.

Para las empresas que compran productos y software, lo mejor es apoyar a las firmas que han adoptado DevSecOps. Hacerlo contribuirá en gran medida a garantizar que los dispositivos y el software obtenidos de ellas no sean bombas de tiempo esperando a ser explotadas por atacantes cada vez más hábiles.

Visita las páginas del blog de Secure Code Warrior para obtener más información sobre DevSecOps y cómo proteger a tu organización y a tus clientes de los estragos de las fallas y vulnerabilidades de seguridad.

¿Quieres profundizar en los errores de seguridad que experimentó Barco?

Juega a estos desafíos gamificados sobre:

• Inyección de comandos del SO en C
• Inyección remota de código en C
• Desbordamiento de búfer en C
• Carga remota de archivos en C
• Credenciales almacenadas en texto plano en C.