El monitor Bluetooth de batería para auto estaba filtrando datos de ubicación

 (haxrob.net)
2 puntos por GN⁺ 2023-06-27 | 1 comentarios | Compartir por WhatsApp
  • La app BM2, que permite revisar el estado de la batería del vehículo, recopilaba no solo coordenadas GPS sino también información de redes Wi-Fi cercanas y de torres celulares, y la enviaba a servidores remotos
  • Los datos se dirigían al servidor bm2.quicklynks.com de Leagend, desarrolladora del producto y la app, y a servidores de AMap, desarrolladora de un SDK de servicios de ubicación; se confirmó que estaban alojados respectivamente en Alibaba Cloud Hong Kong y Beijing
  • Según Google Play, era una app con 100K+ descargas, pero en un principio las etiquetas de privacidad de la tienda indicaban cosas como “no se comparten datos”, “no se recopilan datos” y “cifrado en tránsito”, lo que no coincidía con el comportamiento real
  • En Android, el escaneo Bluetooth requiere permiso de ubicación, así que en la práctica el usuario tenía que conceder ese permiso para usar el dispositivo; en iOS, la función de monitoreo de batería seguía funcionando incluso si se rechazaba el permiso de ubicación
  • Después de la actualización del 25 de julio de 2023, el SDK de AMap fue eliminado de las versiones en ambas tiendas, pero los datos de ubicación GPS siguieron enviándose a un servidor de Alibaba Cloud en Hong Kong, y la app de iPhone también enviaba la dirección del usuario

Los datos de ubicación que enviaba la app del monitor de batería

  • El producto analizado es un monitor Bluetooth de batería que se conecta a los terminales de la batería del auto, se empareja con el smartphone y muestra voltaje/porcentaje, además de ejecutar una prueba de arranque
  • Se compró y analizó un producto de la marca PowerTech en la tienda australiana de electrónica Jaycar Electronics, y parece ser una versión remarcada del Bluetooth 4.0 Battery Monitor de Leagend
  • Productos de la misma familia también se identifican con nombres como la marca Century de Repco, ZX-1689 y Li Battery Monitor
  • La app de Android BM2 registra 100K+ descargas y 1.55K reseñas en Google Play
  • La app BM2 para iPhone también enviaba datos de ubicación a servidores remotos, según el análisis del tráfico de red

Destinos de envío y alcance de la recopilación

  • La app recopilaba no solo el voltaje de la batería, sino también coordenadas GPS, datos de torres celulares cercanas e información de puntos de acceso Wi-Fi cercanos
  • En ese momento, se identificaron dos grupos de destinos para el envío de datos de ubicación
    • Servidor de Leagend / app BM2: bm2.quicklynks.com, 47.244.125.231, Alibaba Cloud Hong Kong
    • Servidor del SDK de AMap: dualstack-cgicol.amap.com, 106.11.130.194, Alibaba Cloud Beijing
  • AMap es un proveedor chino de mapas digitales adquirido por Alibaba, y su SDK recogía no solo GPS sino también otros datos relacionados con ubicación que el teléfono puede recopilar
  • Tras la actualización del 25 de julio de 2023, el SDK de AMap fue eliminado de las apps en ambas tiendas
    • Se detuvo la recopilación de GPS, Wi-Fi y datos de torres celulares que se enviaban a servidores de AMap en China continental
    • Los datos de ubicación GPS siguieron enviándose a un servidor de Alibaba Cloud en Hong Kong
    • La app de iPhone también obtenía y enviaba la dirección del usuario

Etiquetas de privacidad en la tienda y comportamiento real

  • Al 27 de junio de 2023, el desarrollador de la app BM2 actualizó las etiquetas de privacidad en Google Play y Apple App Store para indicar que recopilaba datos de ubicación precisa
  • Antes de eso, lo que mostraba Google Play no coincidía con el comportamiento real de la app
    • “No se comparten datos con terceros”: junto con las estadísticas de la batería se enviaban latitud y longitud a servidores de quicklynks.com; el análisis de fallos se enviaba a umeng.com; y Wi-Fi, torres celulares y coordenadas GPS se enviaban a AMap
    • “No se recopilan datos”: sí se recopilaban datos de ubicación y datos relacionados con la batería
    • “Cifrado en tránsito”: los datos enviados al servidor en la nube de BM2 se transmitían por HTTP sin cifrar
  • El texto detallado de la política de privacidad incluía “Hong Kong” y “location information”

El problema estructural creado por los permisos de Android

  • La app de Android exigía permiso de ubicación para funcionar, y sin ese permiso no era posible usar el dispositivo de hardware
  • Desde Android 6.0, para acceder a identificadores de hardware de dispositivos externos cercanos mediante escaneo Bluetooth y Wi-Fi se requiere ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION
  • Lo que realmente necesita la app BM2 es el escaneo BLE, pero el permiso amplio de ubicación también permite acceder a datos de GPS, torres celulares y Wi-Fi, dejando espacio para abuso
  • En Android 12 o superior, el escaneo BLE puede hacerse solo con el permiso BLUETOOTH_SCAN
  • Según la documentación de Google, a ACCESS_FINE_LOCATION se le puede asignar android:usesPermissionFlags="neverForLocation", pero solo cuando los resultados del escaneo Bluetooth no se usan para inferir la ubicación física

Lo que se confirmó en el tráfico de red

  • Se inspeccionó el tráfico de la app móvil usando el modo WireGuard de Mitmproxy
  • Como BM2 no usa HTTPS, fue posible confirmar en Android y iOS el envío de latitud y longitud sin instalar certificados
  • Después de que la app se conectaba al monitor de batería, enviaba una solicitud POST a http://bm2.quicklynks.com:8080/api/bm2/userDevice/upload?
  • La solicitud incluía campos de latitud y longitud, además de muestras de voltaje de la batería, la dirección MAC del hardware, nickname y serialNo
  • En ese momento, las consultas de DNS e IP mostraban que bm2.quicklynks.com resolvía a 47.244.125.231, y la información de IP apuntaba a un AS de Alibaba en Sham Shui Po, Hong Kong

Las señales de ubicación que manejaba el SDK de AMap

  • El SDK de AMap recopilaba datos de GPS, Wi-Fi y torres celulares
  • Los datos celulares incluían Cell Global Identity
    • MCC: Mobile Country Code
    • MNC: Mobile Network Code
    • MCC + MNC: PLMN, identificador del operador móvil
    • LAC: grupo de torres celulares dentro de un área
    • CI: identificador del transmisor/receptor de la torre celular dentro de un área
    • En 4G se usa TAC
  • Los datos de Wi-Fi incluían la dirección MAC BSSID y el nombre del punto de acceso SSID
  • Los datos de AMap se procesaban en forma de blob binario serializado cifrado antes de escribirse en disco o enviarse por internet
  • Los datos de ubicación se cifraban con una clave AES temporal, y esa clave AES se volvía a cifrar con una clave pública RSA
    • Este método no depende de certificate pinning
    • Sin modificar la app o sin la clave privada RSA correspondiente, es difícil ver el contenido mediante inspección de red tipo man-in-the-middle

Hardware y entorno de prueba

  • El interior del hardware es simple y gira en torno a un regulador de voltaje y al MCU Bluetooth Low Energy Texas Instruments CC2541
  • La CPU del CC2541 está basada en Intel 8051 de 8 bits; las generaciones posteriores de la serie CC usan arquitectura ARM Cortex
  • Los SoC de la serie CC admiten una interfaz dedicada de depuración on-chip, y no se observan JTAG ni SWD
  • El dispositivo admite actualizaciones OTA, y en la parte 3 se documenta un endpoint REST que devuelve el firmware por HTTP
  • No se observó un shunt de detección de corriente ni otro circuito de medición de corriente, por lo que la configuración del hardware es muy simple
  • Las pruebas se realizaron con una batería pequeña de plomo-ácido de 12V, el monitor BM2 y un dispositivo Android rooteado
  • Como los datos de ubicación de AMap solo se escriben de memoria a base de datos cuando se detecta movimiento físico, se realizó instrumentación en tiempo de ejecución con Frida y Objection

Procedimiento de análisis dinámico y estático

  • Las coordenadas GPS pueden alterarse a valores arbitrarios enganchando con Frida android.location.Location.getLatitude y getLongitude
  • Con el plugin Wallbreaker de Objection se confirmaron en el heap de la app instancias de datos de GPS, torres celulares del operador y Wi-Fi
  • El APK se extrajo del dispositivo obteniendo su ruta con adb shell pm path, y luego se descompiló con JADX
  • En AndroidManifest.xml, además de FINE_LOCATION, también aparecían permisos como CAMERA, IMAGE_CAPTURE, ACTION_VIDEO_CAPTURE, MODIFY_AUDIO_SETTINGS y RECORD_AUDIO, aunque se necesita más investigación para saber si esas funciones se usan realmente
  • El punto de entrada de la app es com.stub.StubApp, y se utilizó el empaquetador comercial qihoo.util
  • Con frida-dexdump se volcó desde la memoria en ejecución el bytecode original ejecutable de Dalvik, y luego se convirtió a código Java legible con dex2jar y JADX
  • La app principal de BM2 no tenía ofuscación adicional, pero el SDK de servicios de ubicación amap sí estaba ofuscado, y con la función de deobfuscation de JADX se recuperaron parcialmente algunos nombres de clases

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-06-27
Opiniones de Hacker News

  • Es el resultado de hacer ingeniería inversa a un monitor BLE de batería de auto. Esta app tiene más de 100 mil descargas solo en Google Play.
    Resultó que enviaba continuamente datos de GPS, IDs de celdas de antenas de telefonía móvil y datos de beacons Wi‑Fi a servidores en Hong Kong y China continental. En las páginas de la app en Google y Apple dice que no recopila datos personales ni los envía a terceros.
    Espero que esto sirva como algunos consejos para quienes quieran analizar apps de dispositivos conectados.

    • Parece que también hay una variante BM6, y ahí se indica explícitamente que se puede crear una cuenta personal y hacer seguimiento del vehículo.
      https://www.amazon.de/dp/B0BLG9Z462
      Si haces clic en la tercera imagen aparece una tabla comparativa, y es interesante que lo presenten como una función especial exclusiva del BM6, cuando en realidad es solo una función de la app.
      El código QR del dispositivo [0] apunta a esta app: https://play.google.com/store/apps/details?id=com.dc.bm6
      Por eso también revisé otras URL como https://link.quicklynks.com/bm3.html y https://link.quicklynks.com/bm4.html; esta última redirige a https://www.leagend.com/, que opera este canal de YouTube: https://www.youtube.com/channel/UCqkvyOFP5cXQ02f3h1Ns42Q
      [0] http://link.quicklynks.com/bm6.html
    • Lo peor es que, la última vez que revisé, en Android se necesitaba permiso de ubicación para conectarse a dispositivos BLE. Supongo que es porque se puede estimar la ubicación mediante escaneos BLE.
    • No entiendo por qué 100 mil personas necesitan una app para monitorear la batería del auto. Eso ya se muestra en el tablero; me pregunto qué más les aporta esta app.
      Tampoco sé si vale la pena seguir gastando la batería del teléfono para ver en la pantalla del celular algo que el tablero ya te informa. Si es una batería fija, ¿no bastaría con usar un simple dial analógico de voltímetro?
      Hoy en día es demasiado difícil encontrar dispositivos independientes que funcionen sin app. Por ejemplo, me costó encontrar una lámpara LED que permitiera elegir el color con botones en el propio aparato y sin app; encontré una, pero aun así no era posible hacer el ciclo de colores sin app.
      Si la gente no prefiriera estas tonterías, sería más fácil volver a encontrar electrónicos normales.

  • No entiendo por qué en Android el usuario no puede impedir que una app 1) se ejecute al iniciar 2) se ejecute en segundo plano. Como mínimo debería ser un permiso aprobado por el usuario.
    Eso podría bloquear una buena parte de las apps que chupan datos de esta forma; considero que Google también es cómplice.

    • LineageOS antes podía hacer esto y más con un sistema independiente de permisos que le pasaba datos falsos a las apps, sin que la app pudiera quejarse. Google hizo que eliminaran esa función.
    • En este aspecto, el móvil es mucho peor que la experiencia de escritorio de los 90 y los 2000. Se siente como un retroceso evidente; al menos en Windows 98 podías borrar elementos de la carpeta StartUp.
    • Lo que quieres parece más cercano a GrapheneOS.
      https://grapheneos.org/
    • Hace poco me encontré en Android con una app que cada pocas horas mostraba una notificación del estilo: “La app X quería datos de ubicación, así que activó la ubicación”.
      Sé que las apps pueden solicitar que se active la ubicación, pero me sorprendió que una app pudiera activarla unilateralmente, y no encontré forma de bloquearlo.
      Por motivos como estos siento que es difícil confiar en cualquier teléfono.
    • En iOS existe una configuración de actualización de apps en segundo plano que se puede activar o desactivar por app.

  • Casos como este son la razón por la que no debemos dejar de luchar por la privacidad digital y por leyes que la protejan.
    No es una cuestión de “no tengo nada que ocultar”, sino de impedir que terceros vigilen y vendan datos personales sin conocimiento ni consentimiento explícitos.
    Ahora mismo estamos en medio de una guerra total por los datos, y hay que resistir con fuerza.

  • Me irrita que este tipo de cosas se haya vuelto prácticamente la norma cuando para los actores maliciosos casi no hay costo alguno.
    Al leer esto me sentí aliviado de estar usando GrapheneOS. Llevo varios meses usándolo a diario, y todas las apps, al instalarse, reciben o se les niega explícitamente el permiso de red.
    Nunca les doy permiso de red a este tipo de apps locales, ni tampoco a las apps de teclado, que siempre me han dado mala espina.

    • Como los permisos están escondidos y se hace que el usuario confíe casi por completo en la parte en la que es más difícil confiar, estas cosas se han vuelto la norma y se fomentan activamente.
      No es solo ridículo: es abiertamente hostil contra la privacidad y seguridad del usuario.
    • Estoy pensando en pasarme a GrapheneOS, pero me frena que solo funcione en teléfonos Google. Otros sistemas operativos alternativos de Android parecen tener mucha menos compatibilidad; no sé si estoy siendo demasiado paranoico.
    • Me pregunto si se puede controlar qué apps se ejecutan al iniciar y qué apps pueden ejecutarse en segundo plano.

  • Los sistemas operativos deberían convertir el acceso a Internet en un permiso que el usuario pueda conceder o revocar. Creo que Android tenía algo así antes, e iOS no tenía nada salvo para los datos móviles.
    Si compré un dispositivo que dice usar Bluetooth, pero en realidad necesita acceso a Internet, lo voy a devolver.

    • El esquema de permisos de conceder/revocar de Android se agregó después. Antes, en la tienda había que aceptar todos los permisos de una sola vez antes de instalar, y el acceso a Internet era uno de ellos.
      Si no aceptabas, no podías obtener la app. Algunos permisos todavía funcionan así, y muchos pasaron al modelo de conceder/revocar.
      El acceso a Internet sigue siendo un permiso, pero Google Play ya no lo pregunta, así que cualquier app puede tenerlo. Eso sí, si no lo solicita en el manifest, no funciona.
    • Probé NetGuard para bloquear el acceso a Internet de apps específicas en Android.
      https://netguard.me/
    • Estaría bueno poder ver las solicitudes de red que envía y recibe una app.
      Para principiantes, se podrían mostrar los dominios y marcarlos en verde si Apple los puso en una lista de permitidos de alguna manera. Si no están ni en una lista de permitidos ni en una de bloqueados, podrían mostrarse en amarillo o, si los colores confunden, simplemente mostrar el nombre.
      Las apps que hagan solicitudes a dominios en la lista de bloqueados deberían quedar bloqueadas en la App Store hasta una revisión adicional.
      Para usuarios avanzados, estaría bueno poder tocar y ver detalles como el payload y los headers. Esta función hace mucha falta y no parece tan difícil de agregar.
    • Es la parte más absurda. De todos los permisos, los realmente importantes son básicamente solo dos: acceso completo a archivos y acceso a la red. Si una app no puede leer ni escribir datos fuera de su propio almacenamiento, ¿qué importa si tiene permiso de Bluetooth o no?
    • No es un permiso que el usuario conceda directamente, pero las apps de macOS en sandbox tienen un entitlement[1] para acceso a la red. Apple exige sandboxing para todas las apps vendidas en la Mac App Store.
      [1]: https://developer.apple.com/documentation/bundleresources/en...

  • Creo que los proveedores de tiendas de apps deberían eliminar por completo frases como “no se recopilan datos personales ni se transmiten a terceros”.
    En su lugar, deberían advertir: “esta app tiene permisos relacionados con la red, así que puede enviar los datos que quiera a donde quiera”, o “el creador de la app afirma que no entrega datos a terceros, pero nosotros no tenemos forma alguna de verificarlo”.
    En la práctica, Apple o Google no pueden saber qué es un tercero. Los servidores en China y Hong Kong podrían ser de primera parte; quién sabe. Nadie lo sabe salvo el creador de la app.

    • Si uno toca tecnología digital o electrónica relacionada con China, lo correcto es asumir que toda la información personal, información de ubicación y otros datos disponibles se extraen, se recopilan y pueden ser accedidos por el Partido Comunista Chino.
      Puede que al Partido Comunista Chino no le interesen demasiado los datos de una persona en particular, pero le interesan muchísimo los datos agregados. Además, se vuelven muy útiles cuando se combinan con objetivos específicos, como los datos de millones de empleados del gobierno de EE. UU. recopilados durante años [0][1].
      El “gran experimento” de que el comercio abierto y el intercambio llevarían a China hacia la democracia y la libertad fracasó por completo. Al final, solo fortaleció una dictadura despiadada con ambiciones de expansión global. No hay que hacer negocios con China.
      [0] https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
      [1] https://www.nbcnews.com/tech/security/china-spent-years-coll...

  • Hay que darse cuenta de que un dispositivo de monitoreo también va consumiendo lentamente aquello que está monitoreando. Al final terminás en una situación en la que tenés que monitorear activamente el monitor.
    Este dispositivo BLE consume la batería del auto de forma lenta, pero segura. Algún día enviará una alerta y habrá que cargar la batería, pero pronto incluso dejará de enviar alertas.
    Además, también va a chuparse los datos del celular y enviarlos a China, y consumirá la batería del teléfono. Cuesta imaginar un peor regalo para las fiestas; es una rara triple amenaza para el consumidor.

    • Con una batería de auto típica de 70Ah, la corriente de consumo de 1mA de este monitor tardaría 8 años en descargarla. Si recibís una alerta de “queda 25%”, eso significa que solo te quedan 2 años para recargarla.
      Hablando en serio, la autodescarga es aproximadamente un orden de magnitud mayor que la de este monitor.

  • Android necesita una función para dar datos GPS falsos en dispositivos reales. Sería útil para apps que piden GPS sin ningún motivo.
    Si una app de linterna necesita GPS para encenderse, no hay problema. Mi ubicación actual es el monte Kilimanjaro.

    • Android le advierte al usuario que se requiere un permiso relacionado con la ubicación. El problema es que el escaneo Bluetooth necesita ese permiso, y los desarrolladores de apps abusan de eso para recopilar otros datos de ubicación.
      Los desarrolladores incluso intentan explicarle al usuario con un popup algo como “tocá Permitir para que Bluetooth funcione”.
    • En las opciones de desarrollador existe la función mock location. Según entiendo, descargás y seleccionás una app que proporcione “datos de ubicación falsos”, y esa app entrega la ubicación falsa según cómo esté implementada.

  • A estas alturas, es razonable asumir que estos dispositivos están recopilando grandes cantidades de datos y enviándolos a la sede central. Tampoco me sorprendería que los routers TP-Link estuvieran enviando todo a China.
    Aunque esto no se limita a China; también es posible que el iPhone que uso ahora esté enviando todas mis pulsaciones de teclas y datos de ubicación a EE. UU.

    • No me gusta mucho esa forma de pensar de “asumir que seguro es así”. Por ejemplo, si un router TP-Link estuviera enviando datos de vuelta, salvo que usara verdadera tecnología de espionaje, los enviaría como paquetes por Internet pública. Eso se puede verificar.
      Si sospechás que un router TP-Link está enviando todo a un servidor remoto, basta con monitorear el tráfico.

  • Cuando mis amigos se burlan de mi obsesión con la privacidad y la recolección de datos, les muestro justamente casos como este.
    No hay motivos para creer que lo hagan con fines maliciosos, pero en la práctica no hay forma de saberlo. Tal vez sea simple ignorancia o incompetencia.

    • Una de las motivaciones para documentar esto fue generar conciencia y animar a otros a revisar qué hacen los dispositivos y apps dentro de su casa.
      La cantidad de datos de ubicación que recopilan los fabricantes de dispositivos es considerable. Si los están monetizando, me pregunto si eso podría considerarse malicioso incluso sin haberlo revelado al usuario final.
      El AMap SDK que usa la app recopila muchos más datos de ubicación. En este caso parece probable que el objetivo sea mejorar la precisión de los servicios de ubicación y del software de mapas, y no lo veo como algo malicioso en sí mismo.
      Pero si ese comportamiento no se les informó a los usuarios y desarrolladores, la cosa cambia. El sitio está en chino [1], y ni siquiera sé si habrá alguien que lea los términos detallados para comprobarlo.
      [1] https://lbs.amap.com/api/lightweight-android-sdk/download
    • Que la intención no parezca maliciosa no significa que esté bien. Si no tenían nada que ocultar, también es un problema que no hayan sido transparentes sobre la recolección de datos desde el principio.
      Me recuerda a cuando antes pensaba que los botones “Like” de Facebook en todos los sitios web eran inofensivos, hasta que me enteré de lo amplio que era el seguimiento sin consentimiento.
      La forma típica de China es recopilar datos deliberadamente de maneras que parecen inofensivas por fuera, o dejar abiertas de par en par fallas de seguridad que podrían explotarse más adelante. Si los descubren, dicen: “lo sentimos, lo arreglaremos de inmediato”.
      Lo peor es que estas conductas no tienen consecuencias. Google, la UE o la FTC deberían imponer una multa.
    • Que la gente entregue sus datos sin pensarlo demasiado parece un caso particular de la tragedia de los comunes, o quizá su reverso. Claro que no aplica en todas partes, pero adaptarse al usuario más ingenuo tiene un costo.