Após o recente lançamento da tecnologia AirTags da Apple, me perguntei se o sistema de busca offline "Find My" poderia ser usado para fazer upload de dados arbitrários para a Internet a partir de dispositivos não conectados a WiFi ou Internet móvel. Esses dados podem ser transmitidos por Bluetooth Low Energy e coletados por dispositivos Apple próximos. Esses dispositivos, assim que se conectam à Internet, encaminham imediatamente esses dados para os servidores da Apple, de onde podem ser posteriormente recuperados. Essa técnica poderia ser usada por pequenos sensores em ambientes não controlados, de modo a não desperdiçar energia extra usando a Internet móvel. Além disso, pode ser interessante para roubar dados de locais protegidos por uma gaiola de Faraday, se uma pessoa com um iPhone apenas olhar lá.
Teoricamente, isso deveria ser possível: se você conseguir emular dois AirTags, poderá codificar os dados ativando apenas um deles em um determinado momento. Nesse caso, o dispositivo receptor deve verificar qual AirTag estava ativo em que momento e decodificar os dados de volta à sua forma original. No entanto, tal esquema parece ser extremamente não confiável e, talvez, inadequado para uso em situações práticas reais devido à largura de banda de transmissão de dados muito estreita (especialmente levando em consideração a limitação de 16 AirTag no ID Apple , parecia que a quantidade de dados transferido não pode exceder alguns bits por hora).
Portanto, a viabilidade dessa ideia depende de como o sistema é projetado e implementado. Acontece que as decisões para garantir a segurança e a privacidade tomadas ao projetar o mecanismo off-line mostram que o caso que propusemos é muito eficaz como método de penetração e é quase impossível se defender contra ele.
Resultado: Extraia dados transferidos / baixados anteriormente usando um aplicativo Mac dedicado
- Você pode baixar dados arbitrários de dispositivos não conectados à Internet , transmitindo Find My messages via tecnologia BLE (Bluetooth Low Energy) para dispositivos Apple próximos, que baixam os dados para você
- ESP32, ( ) macOS, , : https://github.com/positive-security/send-my
- , - Find My, ,
Localizar meu modem (ESP32) // Localizar meu modem (ESP32)
Dispositivos Apple próximos // Apple
Mobile Tower ou Ponto de acesso Wifi próximos // Torre de celular ou Ponto de acesso Wifi
Dispositivo macOS com aplicativo de recuperação de dados // dispositivo macOS com aplicativo para recuperar dados
Fluxo de dados // fluxo de dados
.
Descrição da rede de pesquisa offline
Felizmente, esse protocolo já foi amplamente revertido por engenharia reversa por um grupo de pesquisadores da Darmstadt University of Technology, que publicou o artigo “Quem pode encontrar meus dispositivos? “Em março de 2021 e como prova de conceito, lançou a implementação de código aberto do OpenHaystack . Com esta implementação, você pode criar seus próprios componentes que são rastreados na rede Apple Find My. Muito obrigado a esta equipe! Foi através do trabalho deles que o nosso aconteceu, e tanto nosso firmware (também feito para prova de conceito) quanto o aplicativo para Mac são baseados em OpenHaystack.
De uma forma ligeiramente simplificada, o princípio do sistema de pesquisa Find My offline é o seguinte:
- AirTag Apple, , , AirTag ( )
- 2 AirTag Bluetooth, , ( 15 )
- , , .., Find My, , ( ECIES)
- Ao procurar dispositivos, o Dispositivo do proprietário emparelhado gera uma lista de chaves públicas substituíveis que o AirTag deve ter usado nos últimos dias e pede à Apple seus hashes SHA256. O back-end da Apple retorna relatórios de localização criptografados para as chaves cujos IDs foram solicitados.
- O dispositivo do proprietário decodifica os relatórios de localização e gera a localização aproximada.
Servidores Apple // Servidores Apple
Dispositivos localizadores // Pesquisando dispositivos Dispositivo
proprietário // Dispositivo proprietário Dispositivo
perdido // Dispositivo perdido
- // Emparelhamento na configuração inicial
- // Transmissão. Apresentação de chave pública Bluetooth
- // Baixar relatórios de localização criptografados
- // Baixar e descriptografar relatórios de localização
FIG. 1. Diagrama de fluxo simplificado de tarefas resolvidas ao localizar dispositivos off-line
Este design muito bonito tem propriedades de segurança características, em particular:
- Proteção de rastreamento contra invasores próximos com chaves públicas removíveis
- Incapacidade de determinar a localização dos usuários Apple
Porém, para nós, neste caso, o mais interessante é o seguinte: a Apple não sabe quais chaves públicas pertencem à sua AirTag e, portanto, quais relatórios de localização são endereçados a você. Portanto, um endpoint solicitando relatórios de localização para um ID de chave específico não executa nenhuma autorização (mas você deve se autenticar com seu ID Apple para acessar o endpoint).
Toda a segurança é garantida no nível de criptografia dos relatórios de localização: a localização só pode ser descriptografada com a chave privada correta e é armazenada apenas no Dispositivo do Proprietário emparelhado, e é impossível captá-la com uma simples força bruta ataque.
Projetando um protocolo de roubo de dados
Isso sugere que o único meio que podemos usar para criptografar dados é a chave pública EC de transmissão (por exemplo, não podemos influenciar as coordenadas GPS, pois o dispositivo de "pesquisa" as adiciona).
Na próxima seção, consideraremos o back-end da Apple como um armazenamento compartilhado de valores de chave pública, onde o hash SHA256 é usado como a chave e o relatório de localização criptografado é usado como o valor. Além disso, as operações principais são as seguintes:
- Você pode verificar se existem relatórios de localização para um hash específico se SHA256
- Você pode adicionar relatórios de localização a um hash SHA256 específico transmitindo a chave pública correspondente
Acho que você já entendeu o curso dos eventos: você pode definir bits arbitrários na chave compartilhada e no armazenamento de valor e consultá-los novamente. Se tanto o remetente quanto o destinatário concordarem com esse esquema de criptografia, dados arbitrários podem ser transmitidos usando-o.
Decidi construir um modem que aceita uma mensagem por meio de uma interface serial e, em seguida, percorre esses dados até que uma nova mensagem seja recebida. Para garantir que possamos distinguir um bit "0" de um bit não definido, transmitiremos diferentes chaves públicas dependendo do valor do bit e consultaremos o receptor para as duas chaves públicas possíveis.
Não há garantia de quando (ou se houver) mensagens de transmissão específicas serão carregadas para o back-end da Apple como relatórios de localização. A questão é que alguns pacotes podem não alcançar nenhum dispositivo Apple, e os dispositivos de busca podem ter atrasos altamente variáveis entre o recebimento de uma mensagem de transmissão e o download de um relatório de localização, que pode depender da conectividade upstream ou do modo de energia. Assim, nossa codificação de dados não deve depender de quais relatórios de posição chegam e em que ordem, e também permitir a recuperação de fluxos de dados parcialmente recebidos - aqueles nos quais alguns bits são completamente perdidos. Para conseguir isso, decidi criptografar um bit de dados por transmissão, junto com um valor de índice indicando,qual bit de mensagem é definido. Graças à mensagem adicional e à ID do modem, o sistema é adequado para uso múltiplo por vários usuários, lidando com várias mensagens.
Então, enviando um bit específico, criamos uma matriz de 28 bytes como "[índice de 4b bits] [4b ID de mensagem] [4b modem ID] [zeros preenchimento ...] [valor de bit]", operamos como um público chave e enviar representações BLE, por exemplo, para transmitir informações "o bit 0 da mensagem 0 é 1".
Para enviar uma mensagem completa, o programa simplesmente itera sobre todos os seus bits e envia a representação para um bit com uma chave pública, na qual o índice e o valor desse bit são criptografados.
Mensagem para codificar // Mensagem para codificar
Chave pública gerada para transmitir // Chave pública gerada para transmissão
Índice de bits // Índice de
bits Valor de bits // Valor de bits
Codificar bits de mensagem em carga útil de transmissão
Ao buscar dados, o aplicativo de recebimento irá gerar os mesmos 28 matrizes de bytes (duas por bit, onde os valores de bit possíveis são 0 e 1) e solicitam um serviço Apple com hashes SHA256 dessas "chaves públicas". Apenas uma dessas chaves deve ter relatórios de localização anexados, que podem então ser interpretados (por exemplo, o bit com índice 0 é 1).
Potenciais bits para consultar // Bits que podem ser potencialmente consultados
Potenciais chaves públicas para testar // Chaves públicas que podem ser testadas
Consultar o back-end da Apple // Consultar a
existência da chave pública do back-end da Apple Decodificar de volta aos dados originais // Descriptografar a chave pública obtenção de dados brutos
Recupera dados enviados anteriormente de um dispositivo macOS conectado à Internet
Nota: você pode enviar não apenas um bit por mensagem, mas, por exemplo, enviar um byte inteiro, que conterá os últimos 8 bits da chave pública. Embora isso exija uma largura de banda de transmissão de dados mais ampla, o receptor agora terá que solicitar 255 IDs de chave diferentes para selecionar / força bruta um byte (compare com 16 IDs de chave na codificação bit a bit).
Implementação
Lado do remetente
No lado do remetente, decidi usar o ESP32 - um microcontrolador completamente comum e barato (e um teste rápido mostrou que ele pode alterar o endereço BT MAC muito mais rápido do que, digamos, um Raspberry Pi baseado em Linux). Na inicialização, o firmware baseado em OpenHaystack transmite uma mensagem padrão codificada e, em seguida, escuta a interface serial (como um loop) para ver se algum novo dado de transmissão chega - e assim por diante até que uma nova mensagem seja recebida ... Ao transmitir uma chave pública, ela precisa ser dividida e codificada nos primeiros 6 bytes no endereço MAC do Bluetooth (todos, exceto os dois primeiros bits, já que o padrão Bluetooth exige que os dois primeiros bits sejam definidos como 1). Nós te referimos a Consulte a seção 6.2 do artigo da Darmstadt University of Technology , onde essa codificação caseira é descrita com mais detalhes.
Eu adicionei um prefixo estático à minha carga útil para não ter problemas com a especificação BT e também incluí um índice de bit incremental nos primeiros 6 bytes da chave pública, resultando em cada bit transmitido com seu próprio BT MAC endereço, apenas no caso de haver um limite de taxa baseado em endereço MAC em qualquer lugar da pilha.
Saída do modem ESP32 no console serial a
Extração de dados
O aplicativo Mac também é baseado no OpenHaystack e usa o mesmo truque com o plug-in AppleMail para enviar solicitações de busca de localização devidamente autenticadas para o back-end da Apple. O usuário é solicitado a inserir um ID de modem de 4 bytes (pode ser definido durante o firmware ESP), após o qual o aplicativo irá selecionar, decodificar e exibir automaticamente uma mensagem com id 0. Em seguida, o usuário pode selecionar outras mensagens ou alterar o modem .
A mensagem é buscada 16 bytes (128 bits) de cada vez (256 IDs de chave são solicitados) até que não haja mais relatórios (para um byte inteiro).
Complicação menor: expiração da chave pública
Depois de implementar os lados do emissor e do receptor, executei o primeiro teste transmitindo e tentando obter um valor de 32 bits. Depois de alguns minutos, consegui obter 23 dos 32 bits, cada um está definitivamente correto e com cerca de 100 relatórios de localização, mas não obtive nenhum relatório para os 9 bits restantes.
Suspeita-se de que algumas das chaves públicas geradas foram rejeitadas por dispositivos Apple próximos durante a fase de criptografia ECIES como chaves públicas inválidas - e isso foi rapidamente confirmado ao tentar carregar cada uma das cargas geradas como chaves públicas codificadas com SEC-1 em uma curva P224 usando Pacote Python fastecdsa: para cada bit para o qual eu não tinha relatórios de localização, o microcontrolador transmitia a chave pública, lançando uma exceção InvalidSEC1PublicKey ao importar a chave fastecdsa.
Um pequeno contexto da criptografia usada aqui:
- O público EC de 28 bytes representa a coordenada X de um ponto específico, codificado com SEC1.
- A chave pública SEC1 geralmente também tem um bit de "sinal" que determina qual das duas coordenadas Y possíveis para uma determinada coordenada X deve ser codificada. Este bit não é transmitido durante a transmissão e não é importante para a data de expiração da chave pública.
- Ao decodificar a chave pública compactada, a coordenada Y correspondente é calculada usando os parâmetros da curva fixa e verificada se a chave é válida. Algumas das chaves públicas geradas falham neste teste. Para obter mais detalhes, consulte a seção 3.2.2 no artigo " Validação de chaves públicas em curvas elípticas ":
Este problema com chaves públicas inválidas pode ser resolvido de pelo menos duas maneiras:
A vantagem da segunda opção é que, para cada bit recebido, também podemos descriptografar os relatórios de localização para determinar em que ponto um determinado bit foi recebido, mas isso requer um pouco mais de processamento computacional. Ao implementar essa opção, descobri que, devido a bugs na implementação da multiplicação da curva elíptica na biblioteca uECC usada para isso, para algumas chaves privadas o ESP calculou chaves públicas diferentes do BoringSSL no Mac e fastecdsa no Python (difusão diferencial acidentalmente apareceu? ) Essas chaves públicas foram consideradas inválidas pela própria função uECC_valid_public_key () do uECC. Portanto, neste projeto piloto, optei pela opção 1.
Mensagem para codificar // Mensagem codificada
Gerar chave pública para codificar // Gerar uma chave pública para codificar
endereço MAC BT // Endereço MAC BT
Teste a validade, caso contrário incremente o contador // Verifique se a chave é válida, se não, aumente o contador em uma
carga útil de anúncio // Carga útil para a apresentação
Codificação e envio da mensagem
Teste / Desempenho
Quando implementamos uma verificação de validação de chave pública, tudo funciona perfeitamente. Não fiz testes extensivos de desempenho nem fiz medições, mas aqui estão algumas estimativas:
- ~3 . ,
- - Mac. 16 ~5
- 1 60 , , , . . , , , , ( , Apple)
CDF // Função de distribuição cumulativa
Mediana… min // Mediana… 26,3 min.
Atraso de publicação (min) // Atraso antes da publicação (min.)
Fig. 8. Atrasos no recebimento de todos os relatórios, considerados em § 7.1 como uma função de distribuição cumulativa.
Atrasos no recebimento de relatórios, medidos por uma equipe da Darmstadt University of Technology, com base nos materiais "Quem pode encontrar meus dispositivos?"
Usos Potenciais
Embora eu estivesse interessado principalmente em verificar a viabilidade do que descrevi, acho que a aplicação prática potencialmente mais comum é baixar leituras de sensor ou quaisquer dados de dispositivos IoT sem um modem de banda larga, cartão SIM, plano de dados ou conectividade Wifi. Considerando que a Amazon usa uma rede semelhante chamada Sidewalk usando dispositivos Echo, pode muito bem haver uma demanda por tais tecnologias. Como o cache de buscadores acumula as transmissões recebidas, permanecendo lá até que uma conexão com a Internet seja estabelecida, os sensores podem enviar dados até mesmo de áreas sem cobertura de rede móvel, caso pessoas com dispositivos passem por tais locais.
Em um mundo de redes de alta segurança , onde a tecnologia combinando lasers e scanners parece ser um truque promissor para fechar as lacunas de ar, os dispositivos da Apple que os visitantes vêm também podem atuar como um intermediário viável para roubar dados de sistemas sem ar.ou quartos protegidos por uma gaiola de Faraday.
Também parece que o protocolo de descoberta offline pode ser usado para drenar o tráfego em iPhones próximos conectados a tarifas ilimitadas . Limitando o número de relatórios de localização que podem ser enviados de um único buscador (255 relatórios / envios porque o byte de contagem é 1), e com cada relatório excedendo 100 bytes, a transmissão de muitas chaves públicas exclusivas pode levar a um aumento significativo. Tráfego de saída do smartphone. Embora eu não tenha percebido nenhuma limitação de frequência para relatórios de localização de saída, também não testei a quantidade de dados que poderia ser consumida.
Como resolver o problema
Como mencionei no início, será difícil para a Apple se defender contra esse tipo de abuso se decidir fazê-lo.
A Apple projetou o sistema com a economia de dados em mente. Eles não podem ler locais não criptografados e não sabem quais chaves públicas pertencem à sua AirTag, ou mesmo a qual chave pública um relatório de localização criptografado em particular está associado (uma vez que eles recebem apenas o hash SHA256 da chave pública).
Diante disso, o limite declarado de 16 AirTags para o Apple ID é interessante, pois me parece que no momento a Apple não está em condições de obrigá-lo a utilizá-lo.
No entanto, é possível apertar ainda mais este sistema, por exemplo, nas duas áreas a seguir:
- BLE. , , AirTag OpenHaystack, AirTag . , , , BLE , , AirTag , , .
- Apple , id id AirTag, id , 15 16 id Apple ID ( id ). , , : Apple ID .
Neste artigo, respondemos à pergunta se é possível baixar dados arbitrários usando dispositivos Apple de outros usuários: definitivamente sim.
O firmware do modem ESP32 e um aplicativo de extração de dados para macOS foram implementados, estão postados no Github , você pode experimentá-los.
Observe que essa implementação é apenas uma "prova de viabilidade" e o "protocolo" em si não é criptografado nem autenticado. Por exemplo, você pode examinar os detalhes de um modem com ID 0x42424242 simplesmente inserindo seu ID (talvez, entretanto, alguém também possa demonstrar que não há autenticação neste protocolo).
Uma nota final: ao preparar este post, percebi que o "byte de status" incluído na visualização BLE está obviamente sendo usado, por exemplo, como um indicador de nível de bateria. Combinado com as chaves privadas geradas deterministicamente que são giradas, isso provavelmente abre outra brecha de vazamento de dados (byte por visualização), mas não testei essa abordagem.
Os servidores em nuvem da Macleod são rápidos e seguros.
Cadastre-se pelo link acima ou clicando no banner e ganhe 10% de desconto no primeiro mês de aluguel de um servidor de qualquer configuração!
