IOT Connect

“Insecure IOT?…”

Introdução

Esta é uma resolução do desafio do Mobile Hacking Lab
onde descobri recentemente que eles estão oferecendo treinamento e laboratórios gratuitos para explorar e praticar suas habilidades de hacking mobile. Então, decidi fazer o curso e praticar os laboratórios.

Visão geral

Ao ler a página do desafio IOT Connect, há uma descrição bem detalhada do objetivo e das habilidades necessárias. Segundo o site:

Objetivo

Explorar uma vulnerabilidade do bradcast Receiver: Sua missão é manipular a funcionalidade do broadcast receiver no aplicativo Android “IOT Connect”, permitindo que você ative o interruptor principal e controle todos os dispositivos conectados. O desafio é enviar um comando de uma forma onde não é possível ser alcançada pelo usuário guest.

Habilidades necessárias

  • Conhecimento básico do desenvolvimento do Android.
  • Compreensão das implicações de segurança dos broadcast receivers.
  • Técnicas de engenharia reversa para analisar e entender o código do aplicativo.

Analise Broadcast

O primeiro passo foi abrir o app e entender as suas funcionalidades, iniciei a aplicação, criei um usuário e fiz o login. Quando tentei um PIN qualquer na tela de MasterSwitch, apareceu a seguinte mensagem: “The master switch can’t be controlled by guests”. Depois de entender que haviam restrições em alguns comandos para os usuários guests eu decompilei o app e comecei os trabalhos de engenharia reversa para obter mais informações do aplicativo.

Utilizando o jadx-gui, comecei olhando o ponto de entrada da aplicação, que é o arquivo AndroidManifest.xml. Após uma breve análise notei que o broadcast receiver está com a opção exported="true"


Após procurar pelo nome “MasterReceiver” que é o nome desse componente, encontrei ele declarado dentro da classe “CommunicationManager”.


Após abrir o código dessa classe, notei que essa aplicação não possui nenhum tipo de ofuscação. Após olhar o trecho de código a seguir.


Analise Intent

Descobri as seguintes coisas:

  • A action “MASTER_ON” tem uma string extra chamada “key” que é o PIN da tela Master Switch;

  • O código verifica o valor “key” em um pacote a parte com um segredo chumbado dentro da aplicação;

  • Se o PIN estiver correto, a aplicação irá ligar todos os dispositivos e a mensagem de sucesso será exibida;

  • Caso contrário, aparecerá a mensagem “Wrong PIN!!”.


Sabendo dessas informações, utilizei o comando adb para tentar criar o meu payload e enviar o valor da chave utilizando a “action” da intent “MASTER_ON”


Como demonstrado na imagem a aplicação devolve sempre a mensagem “Wrong PIN!!” independente do valor que eu enviar.

A princípio pensei em fazer um ataque de força bruta, mas enquanto a aplicação estiver a mostrando a primeira mensagem, é necessário esperar ela desaparecer para que a próxima possa ser exibida. Assim acaba ficando bem demorado o processo de força bruta.

Dando sequência a análise de código percebi que a aplicação realiza o log da mensagem: “All devices are turned on”


Então, decidi criar um shell script para automatizar este processo.

Exploit

A ideia era enviar um broadcast com um valor do PIN num For Loop e enquanto meu script lê os registos de log do app para que uma vez que a mensagem desejada fosse logada isso significaria que o meu PIN estaria correto independente da mensagem que estivesse na tela.

O shell script fará o trabalho duro e tentará todas as combinações, já que o aplicativo nos diz que o PIN são 3 dígitos.


Depois de executar o script e ter o valor correto, para confirmar o PIN eu fiz o comando: adb shell am broadcast -a MASTER_ON --ei key 345

Abaixo eu deixei um vídeo da PoC para a demonstração dessa execução!

Video

Referências

me

Under a black flag we shall sail

Posts: