Temparary y los ataques a vehículos Tesla

En los últimos años se han descubierto diferentes vulnerabilidades de los vehículos Tesla. Unas han sido más conocidas que otros. Por ejemplo, está el caso del mítico Flipper Zero que, emitiendo una señal al vehículo puede provocar que se abra el puerto de carga de este. Otro ejemplo más reciente es que, al ser propietario de un Tesla, se puede llegar a abrir y arrancar otro vehículo Tesla del cual no se es propietario.

En este post trataremos las vulnerabilidades que se pueden dar en las comunicaciones entre el vehículo Tesla y la aplicación móvil que permite controlar ciertos aspectos del mismo. Dado que el protocolo utilizado es Bluetooth y que el vehículo siempre estará emitiendo para poder emparejarse con la aplicación del propietario, se puede llegar a capturar los paquetes enviados por el coche que le identifican como el mismo.

Esto permite que, con el uso de la técnica de man-in-the-middle, cuando el usuario decida conectarse al vehículo se empareje con un agente malintencionado que se encuentra en medio de las comunicaciones. Esto se puede llevar a cabo por dos motivos:

• Se realiza una suplantación del vehículo con los datos obtenidos previamente, puesto que el mismo se encuentra emitiendo para poder emparejarse.
• Que tanto el vehículo como la aplicación móvil no realizan una comprobación de que el dispositivo que trata de emparejarse a ellos es quien dice ser. Esta vulnerabilidad es conocida hasta agosto del año 2022.

Tras explicar como se da esta suplantación, trataremos las posibilidades que se dan al usar herramientas como tempararay, mostrada en las conferencias MCH del año 2022. Esta herramienta permite dos tipos de ataque:

• Key Drop
• Rolling Key Attack

En primer lugar, el ataque de Key Drop comienza con una conexión al dispositivo móvil con la aplicación móvil legítima, donde el atacante se hace pasar por el vehículo. Cuando la aplicación (legítima) trate de comunicarse con el falso vehículo, el atacante le responderá que no se encuentra en la lista de permisos whitelisted, y esto hará que la aplicación (legítima) solicite la lista de permisos. El atacante enviará entonces la lista de permisos vacía, provocando que el propio dispositivo móvil deshabilite la llave que posee, y requiriendo que haya que desbloquear el vehículo por medio de la tarjeta NFC.

En segundo lugar, el ataque de Rolling Key Attack trata de solicitar una clave excesivamente grande para la aplicación. Este ataque comienza igual que el anterior: se realiza una conexión entre el dispositivo móvil con la aplicación móvil legítima y un atacante que se hace pasar por el vehículo. Cuando se realice la conexión, el atacante mandará un error comunicando que el tamaño del contador criptográfico es menor del que debiera, con lo que la aplicación (legítima) solicitará un nuevo valor, a lo que el atacante responderá solicitando un valor suficientemente grande para que el dispositivo no pueda llegar a realizar las comunicaciones, en este caso 32-bit integer (unsigned). Esto provocará que la aplicación deba volver a ser instalada para restaurar los valores iniciales, de lo contrario no se podrán a establecer las comunicaciones correctamente.

Estas vulnerabilidades aprovechan que los dispositivos no llegan siempre a confirmar que el vehículo o la aplicación son quien dicen ser, o el token que se envía no llega a actualizarse tanto como debiera. Aunque estas vulnerabilidades, por si solas, son más una molestia para el usuario que una amenaza real de robo, si se utilizan junto con otras vulnerabilidades, pueden llegar a ser realmente peligrosas.

Si se desea un análisis en profundidad sobre las vulnerabilidades presentadas o la aplicación en concreto se recomienda revisar la charla dada en la MCH 2022 o ver la propia aplicación en el github público tempararay