Tras el reciente lanzamiento de la tecnología AirTags de Apple, me pregunté si se podría abusar del sistema de búsqueda sin conexión "Find My" para cargar datos arbitrarios a Internet desde dispositivos no conectados a WiFi o Internet móvil. Estos datos podrían transmitirse a través de Bluetooth Low Energy y ser recogidos por dispositivos Apple cercanos. Estos dispositivos, tan pronto como se conectan a Internet, reenvían inmediatamente estos datos a los servidores de Apple, desde donde se pueden recuperar posteriormente. Esta técnica podría ser utilizada por pequeños sensores en entornos no controlados, para no desperdiciar energía extra utilizando Internet móvil. Además, podría ser interesante para robar datos de lugares protegidos por una jaula de Faraday, si una persona con un iPhone simplemente mirara allí.
Teóricamente, esto debería ser posible: si logras emular dos AirTags, entonces puedes codificar los datos activando solo uno de ellos en un momento dado. En este caso, el dispositivo receptor debe verificar qué AirTag estaba activo en qué momento y decodificar los datos a su forma original. Sin embargo, tal esquema parece ser extremadamente poco confiable y, quizás, inadecuado para su uso en situaciones prácticas reales debido al ancho de banda de transmisión de datos muy estrecho (especialmente teniendo en cuenta la limitación de 16 AirTag en Apple ID , parecía que la cantidad de datos transferidos no pueden exceder unos pocos bits por hora).
Por tanto, la viabilidad de esta idea depende de cómo se diseñe e implemente el sistema. Resulta que las decisiones para garantizar la seguridad y la privacidad tomadas al diseñar el mecanismo offline muestran que el caso que propusimos es muy efectivo como método de penetración, y es casi imposible defenderse de él.
Resultado: extraiga los datos transferidos / descargados previamente utilizando una aplicación Mac dedicada
- Puede descargar datos arbitrarios de dispositivos no conectados a Internet transmitiendo Find My messages a través de la tecnología BLE (Bluetooth Low Energy) a dispositivos Apple cercanos, que luego descargan los datos por usted
- ESP32, ( ) macOS, , : https://github.com/positive-security/send-my
- , - Find My, ,
Buscar mi módem (ESP32) // Buscar mi módem (ESP32)
Dispositivos Apple cercanos //
Torre móvil Apple o punto de acceso Wifi cercano // Torre celular o punto de acceso Wifi
Dispositivo macOS con aplicación de recuperación de datos // Dispositivo macOS con aplicación para recuperar datos
Flujo de datos // flujo de datos
.
Descripción de la red de búsqueda sin conexión
Afortunadamente, este protocolo ya ha sido modificado en gran medida por un grupo de investigadores de la Universidad Tecnológica de Darmstadt, que publicó el artículo “¿Quién puede encontrar mis dispositivos? “En marzo de 2021 y como prueba de concepto, se lanzó la implementación de código abierto de OpenHaystack . Con esta implementación, puede crear sus propios componentes que se rastrean en la red Apple Find My. ¡Muchas gracias a este equipo! Fue a través de su trabajo que el nuestro pudo llevarse a cabo, y tanto nuestro firmware (también hecho como prueba de concepto) como la aplicación para Mac se basan en OpenHaystack.
En una forma ligeramente simplificada, el principio del sistema de búsqueda Find My offline es el siguiente:
- AirTag Apple, , , AirTag ( )
- 2 AirTag Bluetooth, , ( 15 )
- , , .., Find My, , ( ECIES)
- Al buscar dispositivos, el dispositivo del propietario emparejado genera una lista de claves públicas reemplazables que AirTag debe haber usado en los últimos días y le pide a Apple sus hashes SHA256. El backend de Apple devuelve informes de ubicación cifrados para aquellas claves cuyas ID se solicitaron.
- El dispositivo del propietario decodifica los informes de ubicación y genera la ubicación aproximada.
Servidores de Apple // Servidores de Apple
Dispositivos de búsqueda // Dispositivos de búsqueda Dispositivo
propietario // Dispositivo propietario Dispositivo
perdido // Dispositivo perdido
- // Emparejamiento en la configuración inicial
- // Transmisión. Presentación de clave pública Bluetooth
- // Descargar informes de ubicación encriptados
- // Descargar y descifrar informes de ubicación
Higo. 1. Diagrama de flujo simplificado de las tareas resueltas cuando se encuentran dispositivos sin conexión
Este hermoso diseño tiene propiedades de seguridad características, en particular:
- Protección de seguimiento contra atacantes cercanos con claves públicas extraíbles
- Incapacidad para determinar la ubicación de los usuarios de Apple
Sin embargo, para nosotros en este caso, lo más interesante es este: Apple no sabe qué claves públicas pertenecen a su AirTag y, en consecuencia, qué informes de ubicación están dirigidos a usted. Por lo tanto, un punto final que solicita informes de ubicación para una identificación de clave específica no realiza ninguna autorización (pero debe autenticarse con su ID de Apple para acceder al punto final).
Toda la seguridad está garantizada en el nivel de cifrado de los informes de ubicación: la ubicación solo se puede descifrar con la clave privada correcta, y se almacena solo en el Dispositivo del propietario emparejado, y es imposible detectarlo con una simple fuerza bruta ataque.
Diseñar un protocolo de robo de datos
Esto sugiere que el único medio que podemos usar para cifrar los datos es la clave pública EC de transmisión (por ejemplo, no podemos influir en las coordenadas GPS, ya que el dispositivo de "búsqueda" las agrega).
En la siguiente sección, consideraremos el backend de Apple como un almacén compartido de valores de clave pública, donde el hash SHA256 se usa como clave y el informe de ubicación encriptado se usa como valor, además, las operaciones principales son las siguientes:
- Puede verificar si existen informes de ubicación para un hash específico si SHA256
- Puede agregar informes de ubicación a un hash SHA256 específico transmitiendo la clave pública correspondiente
Creo que ya comprende el curso de los eventos: puede establecer bits arbitrarios en la clave compartida y el almacén de valores y consultarlos nuevamente. Si tanto el remitente como el receptor están de acuerdo con tal esquema de encriptación, entonces se pueden transmitir datos arbitrarios usándolo.
Decidí construir un módem que acepte un mensaje a través de una interfaz en serie y luego recorra esos datos hasta que se reciba un nuevo mensaje. Para asegurarnos de que podemos distinguir un bit "0" de un bit no establecido, transmitiremos diferentes claves públicas dependiendo del valor del bit, y consultaremos al receptor por las dos posibles claves públicas.
No hay garantía de cuándo (o si lo hay) mensajes de transmisión específicos se cargarán en el backend de Apple como informes de ubicación. El punto es que algunos paquetes pueden no llegar a ningún dispositivo Apple, y los dispositivos de búsqueda pueden tener retrasos muy variables entre la recepción de un mensaje de difusión y la descarga de un informe de ubicación, lo que puede depender de la conectividad ascendente o del modo de alimentación. Por lo tanto, nuestra codificación de datos no debería depender de qué informes de posición lleguen y en qué orden, y también permitir la recuperación de flujos de datos recibidos parcialmente, aquellos en los que algunos bits se pierden por completo. Para lograr esto, decidí encriptar un bit de datos por transmisión, junto con un valor de índice que indica,qué bit de mensaje está establecido. Gracias al mensaje adicional y la identificación del módem, el sistema es adecuado para múltiples usos por parte de múltiples usuarios, manejando múltiples mensajes.
Entonces, al enviar un bit específico, creamos una matriz de 28 bytes como "[índice de 4b bits] [ID de mensaje 4b] [ID de módem 4b] [relleno de ceros ...] [valor de bit]", lo operamos como un Representaciones de clave y envío BLE, por ejemplo, para difundir información "el bit 0 del mensaje 0 es 1".
Para enviar un mensaje completo, el programa simplemente itera sobre todos sus bits y envía la representación a un bit con clave pública, en el que se cifra el índice y el valor de este bit.
Mensaje para codificar // Mensaje para codificar
Clave pública generada para transmitir // Clave pública generada para transmisión
Índice de bits // Índice de
bits Valor de bits // Valor de bits
Codificar los bits del mensaje en la carga útil de transmisión
Al obtener datos, la aplicación receptora generará los mismos 28 -byte arrays (dos por bit, donde los posibles valores de bit son 0 y 1) y solicita un servicio de Apple con hash SHA256 de estas "claves públicas". Solo una de estas claves debe tener informes de ubicación adjuntos, que luego se pueden interpretar (por ejemplo, el bit con índice 0 es 1).
Posibles bits para consultar // Bits que potencialmente pueden consultarse
Posibles claves públicas para probar // Claves públicas que potencialmente pueden probarse
Consultar Apple Backend // Consultar la
existencia de la clave pública del backend de Apple Decodificar los datos originales // Descifrar la clave pública mediante obtener datos sin procesar
Recupera datos enviados previamente desde un dispositivo macOS conectado a Internet
Nota: puede enviar no solo un bit por mensaje, sino, por ejemplo, enviar un byte completo, que contendrá los últimos 8 bits de la clave pública. Si bien esto requiere un ancho de banda de transmisión de datos más amplio, el receptor ahora tendrá que solicitar 255 ID de clave diferentes para seleccionar / fuerza bruta un byte (comparar con 16 ID de clave cuando se codifica bit a bit).
Implementación
Lado del remitente
En el lado del remitente, decidí usar ESP32, un microcontrolador completamente ordinario y barato (y una prueba rápida mostró que puede cambiar la dirección BT MAC mucho más rápido que, digamos, una Raspberry Pi basada en Linux). En el arranque, el firmware basado en OpenHaystack transmite un mensaje predeterminado codificado y luego escucha la interfaz en serie (como un bucle) para ver si llega algún nuevo dato de transmisión, y así sucesivamente hasta que se recibe un nuevo mensaje ... Al transmitir una clave pública, debe dividirse y codificarse en los primeros 6 bytes de la dirección MAC de Bluetooth (todos menos los dos primeros bits, ya que el estándar Bluetooth requiere que los dos primeros bits se establezcan en 1). Te referimos a Consulte la sección 6.2 del artículo de la Universidad Tecnológica de Darmstadt , donde se describe con más detalle esta codificación casera.
Agregué un prefijo estático a mi carga útil para no tener problemas con la especificación BT, y también incluí un índice de bits incremental en los primeros 6 bytes de la clave pública, lo que resulta en que cada bit que se transmite tiene su propio BT MAC dirección, por si acaso hay un límite de velocidad basado en la dirección MAC en cualquier lugar de la pila.
Salida del módem ESP32 en la consola serie a
Lado de extracción de datos
La aplicación para Mac también se basa en OpenHaystack y utiliza el mismo truco con el complemento AppleMail para enviar solicitudes de búsqueda de ubicación debidamente autenticadas al backend de Apple. Se le pide al usuario que ingrese una ID de módem de 4 bytes (se puede configurar durante el firmware ESP), después de lo cual la aplicación seleccionará, decodificará y mostrará automáticamente un mensaje con ID 0. Luego, el usuario puede seleccionar otros mensajes o cambiar el módem .
El mensaje se recupera 16 bytes (128 bits) a la vez (se solicitan 256 ID de clave) hasta que no quedan informes (para un byte completo).
Complicación menor: caducidad de la clave pública
Después de implementar tanto el lado del remitente como el del receptor, ejecuté la primera prueba transmitiendo y tratando de obtener un valor de 32 bits. Después de un par de minutos, pude obtener 23 de 32 bits, cada uno es definitivamente correcto y con aproximadamente 100 informes de ubicación, pero no obtuve ningún informe de ese tipo para los 9 bits restantes.
Se sospecha que algunas de las claves públicas generadas fueron rechazadas por dispositivos Apple cercanos durante la fase de cifrado ECIES como claves públicas no válidas, y esto se confirmó rápidamente al intentar cargar cada una de las cargas útiles generadas como claves públicas codificadas en SEC-1 en una curva P224 utilizando Paquete Python fastecdsa: por cada bit para el que no tenía informes de ubicación, el microcontrolador transmitía la clave pública, lanzando una excepción InvalidSEC1PublicKey al importar la clave fastecdsa.
Un pequeño contexto del cifrado utilizado aquí:
- El público EC de 28 bytes representa la coordenada X de un punto en particular, codificado con SEC1.
- La clave pública SEC1 generalmente también tiene un bit de "signo" que determina cuál de las dos posibles coordenadas Y para una determinada coordenada X debe codificarse. Este bit no se transmite durante la transmisión y no es importante para la fecha de vencimiento de la clave pública.
- Al decodificar la clave pública comprimida, la coordenada Y correspondiente se calcula utilizando los parámetros de la curva fija y se verifica si la clave es válida. Algunas de las claves públicas generadas no superan esta prueba. Para más detalles, consulte la sección 3.2.2 del artículo " Validación de claves públicas en curvas elípticas ":
Este problema con las claves públicas no válidas se puede resolver de al menos dos formas:
La ventaja de la segunda opción es que por cada bit recibido, también podríamos descifrar los informes de ubicación para determinar en qué punto se recibió un bit dado, pero esto requiere un poco más de procesamiento computacional. Al implementar esta opción, descubrí que debido a errores en la implementación de la multiplicación de curvas elípticas en la biblioteca uECC utilizada para esto, para algunas claves privadas, ESP calculó claves públicas diferentes que BoringSSL en Mac y fastecdsa en Python (¿el fuzz diferencial ingresó accidentalmente? ). Estas claves públicas incluso fueron consideradas inválidas por la propia función uECC_valid_public_key () de uECC. Por lo tanto, en este proyecto piloto, me decidí por la opción 1.
Mensaje para codificar // Mensaje codificado
Generar clave pública para codificar // Generar una clave pública para codificar
BT MAC address // BT MAC address
Probar validez, de lo contrario incrementar el contador // Verificar si la clave es válida, si no, aumentar el contador en una
carga útil de publicidad // Carga útil para la presentación
Codificación y envío del mensaje
Pruebas / rendimiento
Cuando hemos implementado una verificación de validación de clave pública, todo funciona a la perfección. No he realizado pruebas de rendimiento exhaustivas ni he realizado mediciones, pero aquí hay algunas estimaciones:
- ~3 . ,
- - Mac. 16 ~5
- 1 60 , , , . . , , , , ( , Apple)
CDF // Función de distribución acumulada
Mediana… min // Mediana… 26,3 min.
Retraso de publicación (min) // Retraso antes de la publicación (min.)
Fig. 8. Retrasos en la recepción de todos los informes, considerados en el § 7.1 como una función de distribución acumulativa
Retrasos en la recepción de informes, medidos por un equipo de la Universidad Tecnológica de Darmstadt, basados en los materiales "¿Quién puede encontrar mis dispositivos?"
Usos potenciales
Si bien estaba interesado principalmente en verificar la viabilidad de lo que describí, creo que la aplicación práctica potencialmente más común es descargar lecturas de sensores o cualquier dato de dispositivos IoT sin un módem de banda ancha, tarjeta SIM, plan de datos o conectividad Wifi. Considerando que Amazon usa una red similar llamada Sidewalk usando dispositivos Echo, bien puede haber una demanda de tales tecnologías. Dado que la memoria caché de los buscadores acumula las transmisiones recibidas, permaneciendo allí hasta que se establece una conexión a Internet, los sensores pueden enviar datos incluso desde áreas sin cobertura de red móvil, si las personas con dispositivos caminan por esos lugares.
En un mundo de redes de alta seguridad , donde la tecnología que combina láseres y escáneres parece ser un truco prometedor para cerrar las brechas de aire, los dispositivos de Apple con los que vienen los visitantes también pueden actuar como intermediarios viables para robar datos de sistemas con brechas de aire.o habitaciones protegidas por una jaula de Faraday.
También parece que el protocolo de descubrimiento fuera de línea podría usarse para drenar el tráfico en iPhones cercanos conectados a tarifas ilimitadas . Al limitar la cantidad de informes de ubicación que se pueden enviar desde un solo buscador (255 informes / envíos porque el byte de recuento es 1), y con cada informe que excede los 100 bytes, la difusión de muchas claves públicas únicas puede conducir a un aumento significativo. Tráfico saliente desde el teléfono inteligente. Aunque no noté ninguna limitación de frecuencia para los informes de ubicación salientes, tampoco probé cuántos datos se podían consumir.
Cómo solucionar el problema
Como mencioné al principio, será difícil para Apple defenderse de este tipo de abuso si así lo deciden.
Apple diseñó el sistema teniendo en cuenta la economía de datos. No pueden leer ubicaciones no cifradas y no saben qué claves públicas pertenecen a su AirTag, o incluso a qué clave pública está asociado un informe de ubicación cifrado en particular (ya que solo reciben el hash SHA256 de la clave pública).
En este sentido, el límite establecido de 16 AirTags para Apple ID es interesante, ya que me parece que en este momento Apple no puede obligar a usarlo.
Sin embargo, es posible un mayor ajuste de este sistema, por ejemplo, en las dos áreas siguientes:
- BLE. , , AirTag OpenHaystack, AirTag . , , , BLE , , AirTag , , .
- Apple , id id AirTag, id , 15 16 id Apple ID ( id ). , , : Apple ID .
En este artículo, respondimos a la pregunta de si es posible descargar datos arbitrarios utilizando dispositivos Apple propiedad de otros usuarios: definitivamente sí.
Se implementó el firmware del módem ESP32 y una aplicación para extraer datos para macOS, están publicados en Github , puedes experimentar con ellos.
Tenga en cuenta que esta implementación es solo una "prueba de viabilidad", y el "protocolo" en sí no está encriptado ni autenticado. Por ejemplo, puede examinar los detalles de un módem con ID 0x42424242 simplemente ingresando su ID (tal vez, mientras tanto, alguien también pueda demostrar que no hay autenticación en este protocolo).
Una nota final: mientras preparaba esta publicación, noté que el "byte de estado" incluido en la vista BLE obviamente se usa, por ejemplo, como indicador de nivel de batería. Combinado con las claves privadas generadas de forma determinista que se rotan, esto probablemente abre otro agujero de fuga de datos (byte por vista), pero no he probado este enfoque.
Los servidores en la nube de Macleod son rápidos y seguros.
Regístrese usando el enlace de arriba o haciendo clic en el banner y obtenga un 10% de descuento durante el primer mes de alquiler de un servidor de cualquier configuración.
