Local,Rio de Janeiro, BR
+ 55 21 99631-6175
contato@onzzi.com.br

Hackeando Drone DJI

Conhecimento é poder

Hackeando Drone DJI

A DJI é líder mundial na indústria de tecnologia de imagens aéreas e drone civis.

Além dos consumidores, no entanto, também conquistou uma grande fatia do mercado corporativo, com clientes provenientes dos setores de infra-estrutura crítica, manufatura, agricultura, construção, gerenciamento de emergência e muito mais. Com tantos clientes em todo o mundo, tanto consumidores quanto corporativos, os drones DJI podem obter dados e imagens de uma ampla gama de pontos de vista e através de um amplo espectro de assuntos.

Uma vulnerabilidade concederia a um atacante acesso à conta DJI de um usuário sem que o usuário soubesse disso. Isso pode fornecer acesso a:

  • Registros de vôo, fotos e vídeos gerados durante os vôos de drone, se um usuário de DJI os tivesse sincronizado com os servidores de nuvem da DJI. (Os registros de voo indicam a localização exata de um drone durante todo o voo, bem como pré-visualizações de fotos e vídeos tirados durante o voo.)
  • Uma visão de câmera ao vivo e visão de mapa durante vôos de drone, se um usuário de DJI estivesse usando o software de gerenciamento de voo FlightHub da DJI.
  • Informações associadas à conta de um usuário do DJI, incluindo informações do perfil do usuário.

A vulnerabilidade foi acessada através do DJI Forum, um fórum online que a DJI realiza para discussões sobre seus produtos. Um usuário que fez login no DJI Forum e, em seguida, clicou em um link malicioso, poderia ter suas credenciais de login roubadas para permitir acesso a outros ativos on-line do DJI:

  • Plataforma web do DJI (conta, loja, fórum)
  • Dados do servidor de nuvem sincronizados dos aplicativos piloto GO ou GO 4 da DJI
  • FlightHub da DJI (plataforma centralizada de gerenciamento de operações de drone)

A DJI já foi notificada sobre essa vulnerabilidade classificou essa vulnerabilidade como de alto risco.

Diagrama:  Uma visão simplificada dos três fluxos de ataque em potencial.

Análise técnica

Na pesquisa abaixo explica como foi capaz de obter acesso a informações confidenciais de voos com drones DJI, bem como dados confidenciais de usuários, em todas as três plataformas DJI de Website, Mobile App e FlightHub.

Primeiro, porém, explicarei onde reside a vulnerabilidade e como ela funciona.

A vulnerabilidade

Em resumo, a vulnerabilidade reside no processo de identificação do DJI.

O DJI usa um cookie que o invasor pode obter para identificar um usuário e criar tokens ou tickets para acessar suas plataformas. Por meio do uso desse cookie, um atacante pode simplesmente seqüestrar a conta de qualquer usuário e assumir o controle total sobre qualquer uma das contas do DJI Mobile Apps, Conta da Web ou DJI FlightHub.

A investigação no processo de login do site do DJI, pois quería entender como um usuário é identificado pelo backend do DJI e quais parâmetros ou cookies são importantes para o processo de login. Então, deí uma olhada em todo o tráfego que passa pelo cliente (navegador) e pelo backend do DJI.

Logo notei que o DJI usa alguns subdomínios para os serviços que oferece:

  • forum.dji.com
  • account.dji.com
  • store.dji.com

Além disso, o login entre esses domínios usa a estrutura do OAuth. Como resultado, comecei a examinar o tráfego nesses subdomínios.

A partir de nossa análise, descobri que uma solicitação para a URL mobile.php me forneceu informações confidenciais sobre meu usuário de teste de DJI que continham dados como nome de usuário , member_uid , token e muito mais.

Isso foi interessante, pois me levou a entender como o backend do DJI identificou meu usuário e se ele usava o mesmo ID de identificador. Então, observei os cookies usados ​​e descobri que um cookie em particular, chamado “meta-chave”, era o responsável pela identificação do usuário.

Figura : A solicitação do mobile.php

Como meu objetivo agora era obter esse cookie de “meta-chave” por qualquer meio possível, tíve que encontrar um subdomínio desprotegido por um atributo http-only, pois isso impediria que o JavaScript vazasse o cookie.

O subdomínio que atendia às minhas necessidades era forum.dji.com , então comecei a procurar vulnerabilidades nessa plataforma.

Descobrindo a vulnerabilidade

Depois de uma pequena pesquisa, me deparei com a seguinte solicitação GET: https://forum.dji.com/forum.php?mod=ajax&action=downremoteimg&message =

Aqui ví que o parâmetro da mensagem foi refletido na resposta. Mas havia dois obstáculos:

  1. Houve a função “addslashes” que adiciona uma barra aos seguintes caracteres ”’/
  2. A injeção de carga útil do XSS ocorreu em uma função indefinida chamada “ updateDownImageList” que foi importada de algum outro código JavaScript que não tinha em meu contexto.

Presumi que a resposta ao nosso pedido GET se parecia com o seguinte pseudocódigo:

Então, para começar com a função escape, comecei com uma barra invertida e uma citação simples como esta:

parent.updateDownImageList (‘ \’ ‘);

Então, “addslahes” também adicionaria uma barra invertida que escaparia de barra invertida e a transformaria em uma string como esta:

parent.updateDownImageList (‘ \\’  ‘);

Então, agora, preciso lidar com os caracteres restantes ‘); e a função não identificada, “updateDownImageList”.

Para lidar com os personagens restantes, adicionei um simples comentário html como este <! – que criou a seguinte carga:

parent.updateDownImageList (‘ \’ <! –  ‘);

Agora tudo o que me restava era lidar com a função não identificada. Para superar o fato de que essa função não foi definida, tive que defini-la.

Então, acabou se parecendo com isso:

alerta (document.cookie); function updateDownImageList (data) {} <! – 

Figura 3 : Cookies que recebidos.

Um invasor poderia então criar uma carga útil que enviaria o cookie de meta-chave para o site dele. Esse tipo de XSS não seria bloqueado por nenhum Auditor de XSS porque ele reside no próprio JavaScript e não consiste em scripts ou eventos.

Para acionar esse ataque XSS, tudo o que o invasor precisa fazer é escrever uma postagem simples no fórum do DJI, que conteria o link para o payload. Afinal, o DJI limita os links para conteúdos que residem no próprio fórum e, dessa forma, é impossível enviar um link para um site malicioso.

Figura 4: Exemplo de site malicioso vinculado por uma postagem de um possível invasor no fórum do DJI.

Como meu XSS reside no próprio fórum, consegui ignorar a restrição do link. Além disso, como há centenas de milhares de usuários comunicando o fórum da DJI, o invasor nem precisaria compartilhar o link mal-intencionado, pois isso seria feito pelos próprios usuários à medida que avançassem na mensagem e no link.

Depois que adquirir a meta-chave, passei a examinar o processo de login e testei como o backend do DJI processa o login em cada plataforma de DJI, começando com o site da DJI.

Website do DJI

Para obter acesso à conta de qualquer usuário no site da DJI, tudo o que precisávamos era sua “meta-chave”, que é chamada de “mck” no subdomínio, account.dji.com .

Comecei criando uma conta de DJI e logando nela. Ao analisar o processo de login, descobri que ele usa o OAuth para autenticar o usuário entre subdomínios, por exemplo, entre accounts.dji.com para forum.dji.com e de volta para dji.com .

Assim, toda vez que DJI quiser autenticar um usuário, ele envia initData.do com um cookie “mck” e a resposta será um URL de retorno de chamada com um ticket.

Ao navegar para o URL, o usuário será autenticado sem credenciais.

Então, para roubar uma conta, precisamos que:

  1. Entre como atacante no dji.com, depois clique em DJI.COM que nos redirecionará para dji.com.
  2. No pedido initData.do, substitua o valor do cookie “mck” pelo “mck” da vítima (que obtivemos da vulnerabilidade XSS).
  3. Continue com o processo de login e acesse a conta da vítima.

Abaixo está o pedido initData.do:

Figura 5: Pedido initData.do

O DJI App

A fim de seqüestrar uma conta em um aplicativo móvel DJI, é preciso ignorar algumas atenuações que foram implementadas no próprio aplicativo.

É preciso interceptar os pedidos indo do aplicativo para o backend DJI, a fim de investigar o processo de login. Mas aqui encontrei um mecanismo de anulação de SSL, que me impediu de interceptar o tráfego de aplicativos e analisa-lo.

Então, tentei descompilar o aplicativo para entender como ignorar o mecanismo de remoção de SSL. Infelizmente, a descomplicação não foi bem-sucedida porque o aplicativo para dispositivos móveis da DJI usa a proteção SecNeo (empresa de segurança para aplicativos móveis).

De acordo com a SecNeo, as seguintes proteções são fornecidas:

  • Código fonte invertendo a prevenção e proteção de dados confidenciais.
  • App adulteração, reembalagem e prevenção de depuração com recursos anti-hooking.
  • Injeções de código dinâmico e descompilação / desmontagem.

Como resultado, tentamos contornar essas limitações usando o Frida. Na verdade, tentamos anexar ao aplicativo dji.go.v4, mas sem sucesso algum.

Em seguida, verifiquei porque não conseguimos anexar ao processo dji.go.v4 e começamos com o comando: ‘frida-ps –U’ para obter uma lista de todos os processos em execução no nosso dispositivo móvel.

Ao executar este comando, notamos que havia apenas um processo dji.go.v4. No entanto, depois de alguns segundos, notei que outro processo dji.go.v4 apareceu.

Observando o /proc/11194/status, podemos ver que o novo processo gerado é anexado ao primeiro processo e, na verdade, está sendo depurado. É por isso que não pudemos depurar o processo com a Frida – ela já está sendo depurada.

Figura 6: O processo recém-gerado ligado ao primeiro processo dji.go.v4, como visto em Frida.

Descobri que o primeiro processo iniciado não é o depurador, mas sim o aplicativo real. O depurador realmente anexou ao aplicativo real e começou a protegê-lo. Isso significava que havia uma condição de corrida que poderíamos explorar e anexar nossos ganchos ao processo de aplicativo e desanexá-lo antes que o processo do depurador fosse iniciado.

Para contornar isso, copiei o certificado Burp Suit para o telefone celular e geramos a aplicação DJI. Isso iniciou o aplicativo no modo suspenso (antes de o depurador ser inicializado).

Então criei um script Frida que usou a seguinte lógica:

  1. Abra o nosso Burp Suit Certificate e converta para o X509Certificate.
  2. Carregue um KeyStore e coloque o certificado dentro.
  3. Crie TrustManagerFactory e inicialize-o com o KeyStore que acabamos de criar que contém nosso certificado Burp Suit.
  4. Sobrecarregue o SSLContext e conecte o TrustManager ao nosso TrustManager.

Após a conclusão do gancho, retomamos a aplicação suspensa e desconectei dela. 

Desta forma, ignorei a fixação SSL e o tráfego apareceu em meu Burp Suit.

Depois de ignorar o pining SSL, nós configurei um proxy que me permitia interceptar o tráfego do aplicativo Mobile.

Ao analisar o processo de login do aplicativo da web, descobrimos que, uma vez que o usuário insere suas credenciais, o aplicativo móvel envia uma solicitação para /apis/apprest/v1/email_login. A resposta recebida é assim:

{“Código”: 0, “mensagem”: “ok”, “dados”: {“nick_name”: “XXXXXXXXX”, “cookie_name”: “_ meta_key”, ” cookie_key “: ” NTUxNjM2ZTXXXXXXXXXXXXXXNmI2NjhmYTQ5NGMz “, “ativo”: falso, “Email”: “XXXXXXXX@gmail.com”, ” token “: ” XXXXXXXXX2139 “, “validade”: 15275XXXXX, “user_id”: “9629807625XXXXXX”, “register_phone”: “”, “area_code”: “” ”, inner_email ”: False,” subscription ”: false,” vipLevel ”: null,” vipInfos ”: []}}

Os dois parâmetros importantes a serem observados aqui são:

  • “Cookie_key” – Esta é a meta-chave / mck que já conhecemos no fórum DJI.
  • “Token” – Esse parâmetro podemos obter da solicitação mobile.php que descrevemos no início desta publicação de pesquisa.

O processo de invasão de conta

O processo para seqüestrar uma conta é:

  1. Primeiro, o invasor precisa de uma meta-chave e um token para substituir por seus próprios. Então ele envia a meta-chave que ele quer hackear para mobile.php e recebe um token correspondente.
  2. O invasor então insere suas credenciais e uma solicitação de login é enviada.
  3. Quando uma resposta da Etapa 2 é recebida, o invasor substitui o valor cookie_key pela meta-chave da vítima e seu token pelo token da Etapa 1.
  4. O invasor agora tem acesso total à conta da vítima.

Ao explorar a vulnerabilidade do DJI, conforme descrito acima, o invasor pode assumir a conta da vítima e obter acesso a todos os seus voos gravados sincronizados, fotos de drones e muito mais.

Para obter acesso aos arquivos de registro de voo, tudo o que o invasor precisa fazer é sincronizar os registros de voo com seu telefone e todos os registros de voo que foram enviados manualmente para os servidores de nuvem DJI serão salvos localmente em seu telefone. Ele pode simplesmente navegar até a pasta ‘DJI / dji.go.v4 / FlightRecord’ e encontrar todos os arquivos do voo, carregá-los no site e visualizar uma grande quantidade de informações sobre os dados de voo do usuário.

(Observe: as capturas de tela das rotas de voo e das imagens acima foram tiradas com agradecimentos à  empresa X .)

DJI-FlightHub

O DJI-FlightHub é um aplicativo baseado na web desenvolvido para fornecer aos usuários corporativos visuais e gerenciamento completos das operações de seus drones. Na verdade, ele permite que os usuários visualizem suas operações de drone em tempo real de qualquer lugar do mundo, incluindo uma visualização de mapa, uma visualização de câmera ao vivo com a capacidade de ouvir sons e permitir que os usuários vejam a localização exata de cada um dos seus drones. para coordenar as missões.

O DJI-FlightHub tem um aplicativo de desktop para acessar o painel de controle de gerenciamento, um aplicativo piloto para voar o drone e, felizmente para nós, um portal da web para acessar o controle de gerenciamento. O portal da web pode ser encontrado no seguinte URL: www.dji-flighthub.com .

No DJI-FlightHub existe um administrador, capitão e piloto. Os administradores são responsáveis ​​pela conta do DJI-FlightHub e acessam a plataforma DJI-FlightHub, visualizam os dados do voo e criam novos capitães ou pilotos. Os capitães também podem acessar a plataforma DJI-FlightHub e criar novos pilotos. Os pilotos são os que voam com os aplicativos piloto e ligam o drone à conta do DJI-FlightHub.

Com isso em mente, se pudéssemos ter acesso à conta do administrador ou do capitão, poderíamos ver as operações de um drone em tempo real. Para sequestrar uma conta DJI de um administrador ou capitão, precisávamos entender o processo de login do DJI-FlightHub.

Figura 8: A página de login do DJI-FlightHub.

Descobri também que quando você clica em ‘login’ um pedido initData.do é enviado, mas na resposta um ticket não é recebido (semelhante ao que recebemos no portal account.dji.com). Em vez disso, só recebemos um ticket na resposta login.do quando o usuário digita suas credenciais. Como isso não é o mesmo que o account.dji.com normal que usamos para roubar uma conta através do portal da web, tivemos que pensar em outra maneira de roubar uma conta no DJI-FlightHub.

Embora soubéssemos que um ticket pode ser gerado pelo pedido initData.do, por algum motivo, este não era o caso no DJI-FlightHub. Então nós olhamos para o pedido para entender o porquê e notamos que no DJI-FlightHub o pedido initData.do tem um appId de DJI-FlightHub, e é por isso que nós não conseguimos um ticket na resposta. Com isso em mente, pensamos que talvez pudéssemos substituir o aplicativo por algo que sabíamos que poderia funcionar para conseguir um ingresso. Uma vez que um ticket foi recebido, tudo o que tivemos que fazer foi verificar se o ticket de outro appid também funcionaria aqui.

Os passos necessários foram então:

  1. Envie uma solicitação initdata.do de appId = store com o mck do Admin com o objetivo de ser sequestrado e adquirir um ticket na resposta.
  2. Ao efetuar login no FlightHub, intercepte a solicitação, altere o mck na solicitação login.do e, no botão de resposta, para o ticket correspondente recebido na solicitação inidata.do. O invasor será redirecionado para a conta do administrador / vítima.

Além disso, o administrador não receberia qualquer notificação de que um invasor acessou sua conta. Enquanto isso, o invasor teria acesso totalmente desinibido ao login e veria a câmera do drone durante as operações ao vivo de qualquer voo em andamento, ou baixaria os registros de voos gravados anteriormente que haviam sido enviados para a plataforma FlightHub.

Compartilhe
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Comente