Una vulnerabilidad imparcheable pone en riesgo todos los vehículos que usen una computadora para controlar sus instrumentos.
Desde que las computadoras se volvieron omnipresentes en nuestra vida, muchas de las cosas que antes no eran posibles ahora lo son. Eso incluye cosas potencialmente no deseadas.
El inconveniente de que todo tenga una computadora integrada es que virtualmente todo puede ser hackeado. Desde sistemas de vigilancia hasta bombillas, todo está conectado y todo es vulnerable a ataque. Esto va a depender mucho del beneficio que tenga un delincuente por hackear una u otra cosa. Por ejemplo, hackear una bombilla no parece muy lucrativo, pero hackear un vehículo y poder «robarlo de manera remota» sí que parece un buen negocio.
Es por esto que muchos investigadores de seguridad se han abocado a protegernos de los cibercriminales intentando detectar y corregir a tiempo todas las vulnerabilidades que estos puedan usar para cometer sus delitos. Pero, ¿Qué pasa cuando la vulnerabilidad obedece a una falla de diseño? ¿Qué pasa si para arreglar este fallo hubiese que cambiar el producto en sí?
Ante las nuevas amenazas no podemos usar viejas tecnologías
Desde 1989 los vehículos han usado un estándar llamado controller area network (CAN) para que los dispositivos dentro del vehículo puedan comunicarse entre sí. Esto permite que los dispositivos, como, por ejemplo, el sistema de anti bloqueo de frenos (ABS) se comunique con el sistema de diagnóstico para informar que todo va bien. O que los sensores del parking informen la distancia a la que debes detener el vehículo de forma segura.
Este estándar trabaja en función a mensajes llamados frames. Cuando un dispositivo envía una notificación, este genera un frame que se escribe en el CAN y todos los demás dispositivos pueden «ver» el mensaje. Cuando un dispositivo obtiene una lectura fuera de los parámetros esperados, este envía un mensaje de error al CAN, con el objetivo de volver a solicitar el mensaje de lectura y notificar a los otros dispositivos de que ignoren este frame «re solicitado».
Por la manera en cómo está diseñado el estándar, si se sobrecarga el sistema con frames de error, el dispositivo en cuestión es «expulsado» pasando a un estado llamado «BUS off state» en el cual no puede leer o escribir en el BUS. Esto funciona de esta manera para aislar a los dispositivos que están funcionando mal y evitar que active otros dispositivos con mensajes erróneos.
Pero justamente por esta razón, un atacante podría hacer que un dispositivo específico pasara a un estado de «BUS Off» en el cual se desconecta completamente del CAN haciéndolo inoperable. Esto permitiría que un atacante pudiese desactivar, por ejemplo, el ABS o los airbags, produciendo una situación deliberadamente peligrosa.
No es algo que pueda hacerse de manera remota, pero es un riesgo real
Aunque los investigadores informan que para realizar el ataque exitosamente se requiere que se conecte al vehículo un dispositivo especialmente diseñado para ello, las situaciones actuales en las que se puede rentar un vehículo o simplemente, cuando se asigna una flota de vehículos a miembros de una empresa, podrían hacer factible este ataque en la vida real.
Dado que la vulnerabilidad existe en el diseño del protocolo de mensajería del bus CAN utilizado en los chips del controlador CAN, el problema no puede ser parcheado directamente con una actualización OTA (Over the Air). La corrección de esta falla de diseño requiere cambios en los estándares CAN y en toda una generación de vehículos que usan esta especificación. Por lo tanto, por desgracia, no hay remedio para el problema todavía.
Sin embargo, los investigadores recomiendan a los fabricantes adoptar ciertas contramedidas para mitigar el riesgo, como por ejemplo restringir el acceso al puerto de diagnósticos OBD-II. Aunque no pueda ser eliminado por completo, estas contramedidas podrían disminuir el riesgo en los vehículos ya existentes. Además, proponen el uso de encriptación en los mensajes para que sea más difícil falsificarlos y engañar al sistema para sobrecargarlo.
Aunque es un fallo que requiere de acceso físico al vehículo para ser explotado, no descartan la posibilidad de que un atacante que pueda obtener acceso remoto al computador central del vehículo, pueda sobrescribir el firmware y replicar el ataque. Por este motivo indican que los fabricantes deben tomarse seriamente inclusive este tipo de fallos.
Recuerden dejar sus comentarios, alimentan el debate y nos ayudan a mejorar.
Fuente: Trend Micro
Sin respuestas