Plataforma de demostración para ataques extremo a extremo de dispositivos con interfaz OBD-II [Póster]

Plataforma de demostraci´ on para ataques extremo a extremo de dispositivos con interfaz OBD-II Ignacio Guti´ errez∗, Gregorio L´ opez†, Roberto Gesteira-Mi˜ narro‡y Rafael Palacios§ Instituto de Investigaci´ on Tecnol´ ogica Universidad Pontificia Comillas ∗[email protected], †[email protected], ‡r[email protected], §[email protected] Resumen—La ciberseguridad en veh´ ıculos ha cobrado un inter´ es significativo en los ´ ultimos a˜ nos, dada la superficie de ataque que sus sistemas de informaci´ on exponen y el creciente marco normativo en materia de ciberseguridad. Un foco de inter´ es en particular se sit´ ua en dispositivos que se conectan a los puertos de diagn´ ostico a bordo de los veh´ ıculos, cuyo acceso a los buses de comunicaci´ on internos del veh´ ıculo podr´ ıa ser explotado por adversarios mediante las interfaces inal´ ambricas disponibles por estos. En este art´ ıculo se propone una arquitectura para una plataforma de pruebas y demostraci´ on de ataques dirigidos a este tipo de dispositivos que permita a los investigadores de ciberseguridad agilizar los procesos de an´ alisis de vulnerabilidades y auditor´ ıa en estos dispositivos. El dise˜ no se contextualiza sobre un caso de uso en el que se identifica el valor a˜ nadido que pueden aportar al investigador. Index Terms—Ciberseguridad, Veh´ ıculos, Diagn´ osticos a bordo, OBD, Dispositivos empotrados, Android Tipo de contribuci´ on: Investigaci´ on en desarrollo I. INTRODUCCI´ ON En los ´ ultimos a˜ nos, los medios de transporte de uso com´ un en nuestra sociedad han incorporado cada vez m´ as funcionalidades dependientes de los sistemas de informaci´ on. En los veh´ ıculos modernos, consolas centrales de entretenimiento, c´ amaras exteriores e incluso los sistemas b´ asicos de control forman parte de una telara˜ na de ECUs (Electronic Control Units), sistemas empotrados heterog´ eneos de diversas capacidades que trabajan en conjunto para orquestar y supervisar los procesos f´ ısicos que ocurren en un veh´ ıculo como respuesta a las entradas del usuario y del entorno que le rodea. Nuevas funcionalidades y paradigmas, como la interoperabilidad con los dispositivos m´ oviles, la electrificaci´ on de los veh´ ıculos e incluso la conducci´ on asistida o automatizada, resultan en un aumento exponencial en la complejidad de estos sistemas. Como resultado de estos factores, la necesidad de considerar la ciberseguridad en los veh´ ıculos, ahora transformados en peque˜ nos sistemas industriales con una considerable superficie de ataque, cada vez es m´ as alta. Bajo la perspectiva de un adversario, una de las superficies de ataque m´ as atractivas en un veh´ ıculo es el acceso directo a los buses CAN (Controller Area Network) del veh´ ıculo, utilizado por los diversos ECUs como medio de comunicaci´ on mutua. El sistema de diagn´ ostico a bordo (OBD, del ingl´ es On-Board Diagnostics), cuya inclusi´ on y f´ acil acceso a los talleres mec´ anicos est´ a regulada en la Uni´ on Europea bajo el Reglamento (UE) 2018/858 [1] (previamente sobre la Directiva 98/69/EC [2]), constituye una forma de acceder a dichos buses. Aunque la implementaci´ on de un puerto OBD es obligatoria bajo esta normativa, sorprende la ausencia de aplicaci´ on de principios b´ asicos de ciberseguridad como la segmentaci´ on de red en la arquitectura y dise˜ no de los sistemas inform´ aticos de un veh´ ıculo [3]. Como resultado, los puertos OBD pueden utilizarse como medio para explotar vulnerabilidades en sistemas internos del veh´ ıculo en una variedad de escenarios de ataque y con un diverso repertorio de impactos potenciales. El acceso al bus CAN del veh´ ıculo que el puerto OBD ofrece permite, por ejemplo, interactuar con las ventanillas de un coche [4], desbloquear el veh´ ıculo haci´ endose pasar por la ECU que realiza la autenticaci´ on de la llave electr´ onica de ignici´ on [5], e incluso desactivar los frenos durante la marcha [6], [7]. Fuera de su uso en los talleres de servicio de veh´ ıculos, estos puertos de diagn´ ostico cuentan con otros usos populares, que en su mayor´ ıa se materializan en los denominados dongles OBD (Fig. 1): dispositivos de peque˜ no tama˜ no que el usuario conecta al puerto OBD del veh´ ıculo para obtener informaci´ on y telemetr´ ıa sobre este con diversos fines leg´ ıtimos. Por lo general, dichos dispositivos cuentan con conectividad externa, bien por Bluetooth o WiFi para el acceso “auto-servido” por parte del conductor mediante una aplicaci´ on m´ ovil, o bien mediante conexi´ on a la red de datos m´ oviles (M2M) para casos de uso en los que se requiera una gesti´ on centralizada. Por otro lado, el acceso directo al puerto OBD por parte de estos dispositivos es capaz de extender la superficie de ataque a los alrededores del veh´ ıculo obviando la necesidad de interacci´ on f´ ısica [4], o incluso posibilitando la explotaci´ on a trav´ es de Internet si el dispositivo utiliza la red de datos m´ oviles como medio de comunicaci´ on. La creciente complejidad de las plataformas computacionales empotradas en los veh´ ıculos, en combinaci´ on con el elevado impacto potencial en la envolvente de safety del veh´ ıculo como resultado de un ataque con ´ exito, ha despertado en los ´ ultimos a˜ nos un creciente inter´ es por parte de investigadores y expertos en ciberseguridad en auditar plataformas vehiculares y los diversos componentes que conforman su ecosistema con el fin de identificar vulnerabilidades concretas, modelar potenciales amenazas y cadenas de explotaci´ on, desarrollar mitigaciones y protecciones que dificulten los potenciales ciberataques resultantes e informar futuras regulaciones y est´ andares industriales. Uno de los mayores obst´ aculos a la investigaci´ on en este campo tiende a ser el elevado coste de adquisici´ on de un veh´ ıculo que pueda servir como demostrador, suponiendo una considerable barrera econ´ omica. Ante esta problem´ atica, los investigadores en materia de ciberseguridad que buscan experimentar en este campo de estudio desde contextos acad´ emicos y/o industriales requieren de plataformas de pruebas mediante las cuales puedan auditarse este tipo de dispositivos en materia JNIC 2024 ISBN:978-84-09-62140-8 474 Figura 1. Ejemplos de dongles OBD comerciales. De arriba a abajo, izquierda a derecha: (a) BlueDriver (modelo LSB2) de Lemur Vehicle Monitors, (b) Bluetooth OBDII Reader de Bafx Products, (c) lector gen´ erico compatible con el protocolo ELM327. de ciberseguridad a una fracci´ on del coste. Este art´ ıculo propone el dise˜ no de una plataforma de dicha ´ ındole orientada a la auditor´ ıa de dongles OBD mediante la integraci´ on de dispositivos y componentes off-the-shelf, proporcionando a los investigadores un conjunto com´ un de herramientas que permitan la automatizaci´ on de ataques sencillos y asistan en la elaboraci´ on de ataques m´ as complejos. El resto del art´ ıculo se organiza de la siguiente manera: la secci´ on II profundizar´ a sobre los requerimientos identificados sobre los cuales se gu´ ıa la propuesta de dise˜ no. La secci´ on III describir´ a el dise˜ no propuesto atendiendo a dichos requerimientos. La secci´ on IV contextualizar´ a el dise˜ no propuesto mediante un caso de uso centrado en la vulnerabilidad CVE-2016-2354 [8] previamente identificada en dispositivos BlueDriver de la marca Lemur Vehicle Monitors, describiendo c´ omo podr´ ıa utilizarse la plataforma propuesta y las capacidades que ofrece para identificar vulnerabilidades similares. Finalmente, la secci´ on V proporcionar´ a conclusiones y describir´ a el trabajo futuro alrededor de este proyecto. II. AN´ ALISIS DE REQUERIMIENTOS Una auditor´ ıa efectiva de un sistema de informaci´ on requiere considerar su comportamiento en contexto de c´ omo recoge, procesa e interact´ ua con su entorno. En el caso de un dongle OBD, este se comunica principalmente por medio del puerto OBD con el bus CAN del veh´ ıculo, e interact´ ua con otros sistemas o dispositivos mediante interfaces tipo Bluetooth, WiFi o redes m´ oviles M2M (machine-to-machine) seg´ un la l´ ogica definida en su firmware. Bajo el alcance de este estudio, el objetivo principal que se considerar´ a dentro del alcance de las pruebas que se buscan realizar es auditar dispositivos que se comuniquen con una aplicaci´ on m´ ovil v´ ıa Bluetooth. Con el fin de interactuar con el dispositivo, este ofrece un protocolo de alto nivel a trav´ es del cual el usuario puede recoger la informaci´ on del veh´ ıculo y realizar las acciones deseadas. Muchos dispositivos implementan el protocolo propietario ofrecido por el producto ELM327, originalmente desarrollado por ELM Electronics; como resultado, hoy d´ ıa se ha convertido en est´ andar de facto, con un diverso ecosistema de dispositivos y aplicaciones m´ oviles que soportan dicho protocolo. Otros dispositivos implementan protocolos propietarios, en conjunto con aplicaciones m´ oviles espec´ ıficas para acceder al dispositivo en cuesti´ on. Por lo general, un n´ umero significativo de estos dispositivos se comunican con los diversos ECUs v´ ıa el protocolo de bus CAN1con el prop´ osito de recoger telemetr´ ıa del veh´ ıculo y/o mensajes diagn´ osticos, replicando la funcionalidad ofrecida en las herramientas utilizadas por los talleres mec´ anicos para diagnosticar fallos en los diversos subsistemas del veh´ ıculo. Derivado de este contexto, se identifican varias capacidades deseadas de la plataforma a dise˜ nar, centrados por un lado en la superficie de ataque a estudiar, y por otro en los tipos de ataques que se busca realizar. Por un lado, entre las potenciales superficies de ataque que se buscan auditar dentro del alcance de esta plataforma, se encuentran: La aplicaci´ on m´ ovil de interacci´ on con el dispositivo, La propia capa de comunicaci´ on (Bluetooth, WiFi, etc.) mediante la cual la aplicaci´ on se comunica con el dispositivo. Sobre estas superficies de ataque, se busca realizar, entre otros, los siguientes tipos de ataques: Ingenier´ ıa inversa. Control a bajo nivel. Ataques de hombre en el medio (del ingl´ es man-in-themiddle, MitM). Fuzzing. Explotaci´ on de vulnerabilidades a nivel de firmware. Adicionalmente, se identifican una serie de requerimientos no funcionales a considerar en el dise˜ no de la plataforma: 1. Accesibilidad, contando con capacidades y herramientas listas para usar, ofreciendo as´ ı una base mediante la cual realizar ataques y recoger resultados en menor tiempo. 2. Eficacia, asistiendo a los investigadores en las labores de auditor´ ıa mediante la automatizaci´ on de pruebas sencillas, liberando tiempo para pruebas m´ as complejas y especializadas. 3. Extensibilidad, permitiendo su evoluci´ on continua a medida que nuevas innovaciones tecnol´ ogicas llegan al mercado. 4. Coste, permitiendo a una audiencia diversa beneficiarse de las capacidades ofrecidas. III. DESCRIPCI´ ON DE LA SOLUCI ´ ON Para responder a las necesidades identificadas, se ha determinado un dise˜ no que emplea los siguientes componentes (v´ ease Fig. 2): 1. Un dispositivo Android en el cual se pueda instalar la aplicaci´ on proporcionada por el proveedor (o aplicaciones desarrolladas por terceros, en el caso de dongles OBD empleando est´ andares de facto como el protocolo ELM327 previamente mencionado) con la cual comunicarse con el dispositivo a probar. Para el demostrador de esta plataforma, se utiliza un dispositivo Xiaomi Redmi 9. 2. Un simulador de ECU, aparato electr´ onico con un puerto OBD-II al cual se conecta el dispositivo a probar, 1O bien, seg´ un la antig¨ uedad del veh´ ıculo, utilizando otros protocolos como ISO 9141-2 [9]. Plataforma de demostraci´on para ataques extremo a extremo de dispositivos con interfaz OBD-II 475 Controlador central 1 3 Dispositivo a probar 2 Trazas CAN Equipo de investigación Control, ADB... Simulador ECU Figura 2. Diagrama del demostrador con los elementos principales indicados. El robot de Android se reproduce o modifica a partir del trabajo generado y compartido por Google, y se usa conforme a lo descrito en la Licencia de Atribuci´ on de Creative Commons 3.0. present´ andose a este ´ ultimo como una de las ECUs de un veh´ ıculo y proporcionando una emulaci´ on parcial de los mensajes que un veh´ ıculo podr´ ıa intercambiar v´ ıa el bus CAN. Para el demostrador, se utiliza un simulador fabricado y distribuido por Lianghung Co [10]. Este simulador en particular permite la simulaci´ on de m´ ultiples protocolos adem´ as del est´ andar CAN, con la posibilidad adicional de capturar paquetes entrantes en tiempo real. 3. Un controlador central, cuyo prop´ osito es centralizar las labores y herramientas utilizadas en el an´ alisis y experimentaci´ on con el resto de la plataforma. Para el demostrador, se utiliza una Raspberry Pi 4B, con la opci´ on de utilizar un dispositivo de similares caracter´ ısticas. Con respecto a (1), las capacidades de depuraci´ on y an´ alisis ofrecidas por el sistema operativo Android hacen posible estudiar las interacciones entre ambos, interceptar comunicaciones y actualizaciones de firmware e incluso modificar el comportamiento de la aplicaci´ on; esto permite experimentar con una diversa gama de escenarios de ataque, desde ataques MitM tanto en la comunicaci´ on con el dispositivo como en las conexiones a Internet hasta la explotaci´ on de vulnerabilidades en el dongle OBD o incluso en la propia aplicaci´ on m´ ovil. Por otro lado, al evitar requerir el uso de un veh´ ıculo real, el uso de un simulador de ECU (2) simplifica el dise˜ no de la plataforma, reduce su coste total y permite realizar pruebas m´ as arriesgadas que podr´ ıan comprometer la disponibilidad de un veh´ ıculo real. Los diversos componentes de la plataforma se conectan al controlador central (3), y el investigador interact´ ua con estos dispositivos mediante las herramientas disponibles en el controlador central. Por ejemplo, el dispositivo Android se conecta al controlador central mediante USB, y se interact´ ua con este mediante el protocolo ADB (Android Debug Bridge) con el fin de instalar aplicaciones que comuniquen con los dispositivos, monitorizar su comportamiento y realizar labores de depuraci´ on, y gestionar el propio dispositivo Android. Del mismo modo, el simulador de ECU podr´ ıa conectarse mediante USB con el fin de recoger las comunicaciones realizadas en el bus CAN. Adem´ as de estas capacidades, se disponen de herramientas con las cuales interactuar con los dispositivos conectados, y analizar y procesar los datos recibidos. Se propone, entre otros, utilizar el programa de c´ odigo abierto MobSF (Mobile Security Framework) [11] en el controlador central, permitiendo realizar an´ alisis est´ atico y din´ amico sobre la aplicaci´ on Android bajo estudio. Mediante automatismos para gestionar los componentes del sistema y los datos que se recogen de estos, en combinaci´ on con integraciones entre las diversas herramientas seg´ un corresponda, se busca mejorar la eficiencia y estandarizar un marco de trabajo com´ un que ayude al investigador a conseguir resultados m´ as r´ apido. Disponer de un controlador central abierto y compacto con diversas interfaces (WiFi, Bluetooth, USB, SPI, I2C, UART, etc.) permite integrar hardware adicional para expandir y modificar arbitrariamente las capacidades de la plataforma seg´ un requiera la situaci´ on. Por ejemplo, podr´ ıan realizarse ataques a la capa de comunicaci´ on Bluetooth bien con el hardware del propio controlador central o con un adaptador Bluetooth externo, o podr´ ıa interactuarse con el dispositivo en pruebas mediante interfaces de depuraci´ on f´ ısicas como JTAG o UART, dentro de lo que sea posible. IV. CASO DE ESTUDIO Y APLICACI ´ ON A continuaci´ on, se propone un escenario de investigaci´ on utilizando una vulnerabilidad real descubierta en un dispositivo comercial. A partir de este escenario, se identifican en el proceso de investigaci´ on de dicha vulnerabilidad aplicaciones en las que la plataforma pueda aportar un valor a˜ nadido al investigador. En Abril de 2016, una investigaci´ on realizada por Dan Klinedinst, por aquel entonces uno de los investigadores en vulnerabilidades de sistemas TI del CERT/CC (Universidad Carnegie Mellon), identific´ o que los dispositivos BlueDriver comercializados por Lemur Vehicle Monitors no proporcionaban autenticaci´ on sobre la interfaz Bluetooth. A trav´ es de esta se pod´ ıa leer el estado del veh´ ıculo mediante la aplicaci´ on m´ ovil del fabricante [8]. Un adversario en proximidad del veh´ ıculo pod´ ıa, conect´ andose v´ ıa Bluetooth al dispositivo, enviar comandos arbitrarios al puerto OBD-II mediante el cual el dispositivo interact´ ua con el bus CAN del veh´ ıculo, sirviendo como potencial punto de entrada para realizar explotaci´ on adicional. Debe destacarse que no ser´ ıa necesario acceder f´ ısicamente al interior del veh´ ıculo, siendo la comunicaci´ on Bluetooth con el dispositivo el punto de entrada utilizado para explotar la vulnerabilidad. El descubrimiento caus´ o cierto revuelo en los medios de comunicaci´ on [12], [13], y Lemur Vehicle Monitors r´ apidamente liber´ o actualizaciones tanto para su aplicaci´ on m´ ovil como para el firmware del dispositivo en cuesti´ on. La remediaci´ on principal consisti´ o en provocar que el dispositivo dejase de aceptar nuevas conexiones Bluetooth tras un periodo de 60 segundos, forzando a los usuarios a f´ ısicamente desconectar y reconectar el dispositivo del veh´ ıculo para poder conectarse al dispositivo mediante la aplicaci´ on m´ ovil. Adicionalmente, se implement´ o cifrado en la conexi´ on entre la aplicaci´ on y I. Guti´errez, G. L´opez, R. Gesteira-Mi˜narro and R. Palacios 476 el dispositivo, y el protocolo de comunicaci´ on entre ambos cambi´ o para restringir los comandos CAN que la aplicaci´ on pod´ ıa realizar mediante el dispositivo [14]. En el proceso de investigaci´ on de esta vulnerabilidad, la plataforma podr´ ıa aportar valor a˜ nadido en varias actividades: 1. El investigador puede instalar la aplicaci´ on m´ ovil propietaria del proveedor en el dispositivo m´ ovil de la plataforma. Mediante las herramientas de an´ alisis est´ atico y din´ amico que se proporcionan, el investigador puede determinar la falta de autenticaci´ on en la capa de comunicaciones Bluetooth. 2. Del mismo modo, mediante el an´ alisis de la aplicaci´ on y la intercepci´ on de las comunicaciones Bluetooth entre la aplicaci´ on y el dispositivo, el investigador puede determinar que existe la capacidad de enviar tramas CAN arbitrarias a trav´ es del dispositivo, mediante las cuales podr´ ıa llegarse a comprometerse la seguridad del veh´ ıculo. 3. Realizando ingenier´ ıa inversa del protocolo, modificando la aplicaci´ on o incluso alterando la l´ ogica del programa y/o la memoria vol´ atil sobre la cual el programa opera, ser´ ıa posible enviar paquetes arbitrarios al dispositivo; entre otros, esto permitir´ ıa realizar ataques de fuzzing “hechos a medida” sobre el dispositivo siendo auditado, para lo cual existen t´ ecnicas espec´ ıficas de aplicaci´ on en dispositivos IoT [15], [16]. El ´ exito de los ataques podr´ ıa determinarse examinando las comunicaciones ocurridas en el bus CAN, que se registran por el simulador de ECU y se env´ ıan al controlador central. Adicionalmente, podr´ ıan validarse las remediaciones realizadas posteriormente por el fabricante, verificando que arreglan o mitigan las vulnerabilidades originalmente identificadas, y que estas no introducen vulnerabilidades adicionales. Mediante las capacidades que ofrece, la plataforma puede as´ ı asistir en diversas fases del proceso de investigaci´ on. V. CONCLUSIONES Y TRABAJO FUTURO En este trabajo se ha propuesto, en base a un conjunto de requerimientos tanto funcionales como no funcionales, un dise˜ no de una plataforma de pruebas y demostraci´ on para ataques a dongles OBD que busca permitir a los investigadores de ciberseguridad agilizar los procesos de an´ alisis de vulnerabilidades y auditor´ ıa en estos dispositivos, y se ha ilustrado su utilidad a trav´ es un caso de estudio de relevancia en la industria. En trabajo futuro se busca utilizar la plataforma para identificar nuevas vulnerabilidades en varios dispositivos de este tipo, aplicando metodolog´ ıas de auditor´ ıa de seguridad relevantes como IoTSF [17] y BSAM [18]. En una fase inicial, se centrar´ a la investigaci´ on en los dispositivos ilustrados en la Fig. 1. Adicionalmente, se busca experimentar con las capacidades de expansi´ on de la plataforma, a˜ nadiendo funcionalidades como la intercepci´ on de comunicaciones Bluetooth mediante la integraci´ on de chipsets como el NRF52. Finalmente, ser´ ıa posible generalizar y expandir el enfoque el dise˜ no propuesto en este trabajo a efectos de permitir el an´ alisis de otros tipos de dispositivos IoT (Internet-of-Things). REFERENCIAS [1] “Regulation (EU) 2018/858 of the European Parliament and of the Council of 30 May 2018 on the approval and market surveillance of motor vehicles and their trailers, and of systems, components and separate technical units intended for such vehicles, amending Regulations (EC) No 715/2007 and (EC) No 595/2009 and repealing Directive 2007/46/EC (Text with EEA relevance.),” May 2018, legislative Body: EP, CONSIL. [Online]. Available: http://data.europa.eu/eli/reg/2018/858/oj/eng [2] “Directive 98/69/EC of the European Parliament and of the Council of 13 October 1998 relating to measures to be taken against air pollution by emissions from motor vehicles and amending Council Directive 70/220/EEC,” Oct. 1998. [Online]. Available: http://data.europa.eu/eli/dir/1998/69/oj/eng [3] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage, “Experimental Security Analysis of a Modern Automobile,” in 2010 IEEE Symposium on Security and Privacy. Oakland, CA, USA: IEEE, 2010, pp. 447–462. [Online]. Available: http://ieeexplore.ieee. org/document/5504804/ [4] A. Luo and S. Hsieh, “Remotely Hacking a car through an OBD-II Bluetooth Dongle,” Automotive Security Research Group, Jul. 2023. [Online]. Available: https://www.youtube.com/watch?v=f19 BNgVrWQ [5] K. Tindell, “CAN Injection: keyless car theft,” Apr. 2023. [Online]. Available: https://kentindell.github.io/2023/04/03/can-injection/ [6] A. Greenberg, “Hackers Remotely Kill a Jeep on the Highway—With Me in It,” Wired, Jul. 2015, section: tags. [Online]. Available: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ [7] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner, and T. Kohno, “Comprehensive experimental analyses of automotive attack surfaces,” in Proceedings of the 20th USENIX Conference on Security, ser. SEC’11. San Francisco, CA, USA: USENIX Association, 2011, p. 6. [Online]. Available: https://www.usenix.org/legacy/events/sec11/ tech/full papers/Checkoway.pdf [8] D. Klinedinst, “CERT/CC Vulnerability Note VU#615456,” Apr. 2016. [Online]. Available: https://www.kb.cert.org/vuls/id/615456 [9] ISO Central Secretary, “Road vehicles – Diagnostic systems – Part 2: CARB requirements for interchange of digital information,” International Organization for Standardization, Geneva, CH, Standard ISO 9141-2:1994, 1994. [Online]. Available: https://www.iso.org/ standard/16738.html [10] Lianghung Co, “OBD-II ECU Simulator CAN BUS.” [Online]. Available: https://vehelec.com/products/ obd-ii-ecu-simulator-iso15765-iso9141-2-iso14230-can-bus [11] A. Abraham and MobSF Collaborators, “MobSF/MobileSecurity-Framework-MobSF,” Mar. 2024, original-date: 201501-31T04:36:01Z. [Online]. Available: https://github.com/MobSF/ Mobile-Security-Framework-MobSF [12] M. Honorof, “This Bluetooth Car Dongle Might Just Kill You,” Apr. 2016. [Online]. Available: https://www.tomsguide.com/ us/lemur-bluedriver-security-flaw,news-22521.html [13] P. Roberts, “CERT: Aftermarket Add-On Opens Cars To Life Threatening Hacks,” Apr. 2016. [Online]. Available: https://securityledger. com/2016/04/cert-warns-on-hacking-risk-to-bluedriver-plug-in/ [14] BlueDriverSupport, “Reply to ”Friendly PSA: BlueDriver OBD2 Scanner Company (Lemur Vehicle Monitors) Seemingly Pulled from Market”,” Nov. 2018. [Online]. Available: www.reddit.com/r/MechanicAdvice/comments/9t6e7m/friendly psa bluedriver obd2 scanner company/e8ujm1h/ [15] J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. Lau, M. Sun, R. Yang, and K. Zhang, “IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing,” in Proceedings 2018 Network and Distributed System Security Symposium. San Diego, CA: Internet Society, 2018. [Online]. Available: https://www.ndss-symposium.org/ wp-content/uploads/2018/02/ndss2018 01A-1 Chen paper.pdf [16] X. Feng, R. Sun, X. Zhu, M. Xue, S. Wen, D. Liu, S. Nepal, and Y. Xiang, “Snipuzz: Black-box fuzzing of iot firmware via message snippet inference,” 2021. [17] “IoTSF IoT Security Assurance Framework Release 3.0,” Nov. 2021. [Online]. Available: https://iotsecurityfoundation.org/wp-content/uploads/2021/11/ IoTSF-IoT-Security-Assurance-Framework-Release-3.0-Nov-2021-1. pdf [18] Tarlogic, “BSAM: Bluetooth Security Assessment Methodology.” [Online]. Available: https://www.tarlogic.com/bsam/ Plataforma de demostraci´on para ataques extremo a extremo de dispositivos con interfaz OBD-II 477