🚀 A CloudSEK se torna a primeira empresa de segurança cibernética de origem indiana a receber investimentos da Estado dos EUA fundo
Leia mais
Voltar
Vulnerability Intelligence
Testando vulnerabilidades em dispositivos de IoT
Testando vulnerabilidades em dispositivos de IoT
April 14, 2020
min
Tabela de conteúdo
Inscreva-se nos recursos do CloudSEK
Receba as últimas notícias, ameaças e recursos do setor.
O 'S' na IoT
O dicionário urbano define IoT como: um acrônimo para “Internet das Coisas”, por exemplo, objetos do cotidiano (como lâmpadas ou geladeiras) que podem ser acessados e possivelmente controlados pela Internet. A letra 's' na sigla significa segurança de dados e comunicação.
Ainda está se perguntando onde está o 's'?
Embora a segurança dos dispositivos de IoT exija atenção imediata, a abundância desses dispositivos resultou na falta deles. Atualmente, existem mais de 40 bilhões de dispositivos conectados e, todos os dias, um número significativo de dispositivos de IoT é implantado.
Roteadores de Internet, TVs inteligentes, relógios, geladeiras, alto-falantes e sistemas de segurança, como câmeras e dispositivos de automação residencial, são os dispositivos de IoT mais comuns. Alguns dos exemplos menos conhecidos são serviços de máquinas de venda automática inteligentes, como o BBInsta da BigBasket, medidores inteligentes de eletricidade, scooters de aluguel ativados por Bluetooth, como Vogo e Bounce, e purificadores de água RO inteligentes, como o DrinkPrime. E a maioria desses dispositivos já se tornou parte indispensável de nossas vidas.
Por que é importante proteger os dispositivos de IoT?
A crescente demanda por dispositivos inteligentes torna essencial priorizar sua segurança. No entanto, os seguintes motivos também são notáveis:
1. Uso prolongado:
Ao contrário de outros dispositivos tecnológicos, os dispositivos conectados são usados por um longo período de tempo — os roteadores de banda larga ADSL lançados no final dos anos 2000 com componentes de software do início dos anos 2000 ainda estão ativos e online. No entanto, a maioria desses dispositivos não recebe mais atualizações de segurança.
2. Baixa proteção contra ataques:
A maioria dos dispositivos conectados funciona com pouca energia e pouca memória, impossibilitando o uso de técnicas modernas de defesa, especialmente contra vulnerabilidades de corrupção de memória, como estouro de buffer. Além disso, os usuários geralmente encontram a proteção de pilha, o ASLR etc. desativados.
3. Terrenos inexplorados:
O foco principal do setor de segurança é em aplicativos web/desktop. Negligenciando assim a segurança de um grande número de dispositivos de IoT.
Como detectar vulnerabilidades em dispositivos de IoT?
Há várias maneiras de detectar as vulnerabilidades em dispositivos de IoT. Vamos explorar:
- Análise de firmware
- Exploração de serviços
- Engajamento de hardware
1. Análise de firmware
A vantagem dessa abordagem é que ela não exige a presença física do dispositivo de destino. Quando discutirmos as várias maneiras de detectar vulnerabilidades em dispositivos conectados, explicarei como descobri uma vulnerabilidade de execução remota de código que pode ser explorada remotamente em um roteador de Internet altamente distribuído.
Primeiro, baixe o firmware mais recente no site do fabricante do dispositivo, geralmente encontrado na página de suporte relacionada a esse dispositivo. Os fabricantes geralmente fornecem guias de usuário com instruções para atualização manual de software ou no caso de hardware bloqueado.
A ferramenta preferida para essa abordagem é binwalk. É uma ferramenta fácil de usar para analisar, fazer engenharia reversa e extrair imagens de firmware. Além disso, funcionaria em qualquer arquivo binário desconhecido. Ele verifica assinaturas de tipo de arquivo conhecidas dentro do arquivo e detecta sistemas de arquivos e tipos conhecidos de fluxos compactados.
Aqui está uma demonstração da execução do binwalk no firmware do TP-Link Archer C5, o roteador padrão emitido pela ACT, Bangalore.
Em seguida, ele detecta três coisas no arquivo:
- U-Boot — Um bootloader frequentemente usado em dispositivos embarcados,
- Alguns dados compactados e
- Um sistema de arquivos Squash FS — Essas são a imagem e os dados do sistema de arquivos raiz montados no dispositivo. Ele conterá todos os binários, scripts e configurações.
Este firmware usa SquashFS, mas existem outros sistemas de arquivos usados em dispositivos embarcados que podem ser usados:
Para extrair o SquashFS e outros arquivos, pode-se usar o próprio binwalk: `binwalk -e arquivo_de_firmware` ou `unsquashfs`. No entanto, com base no sistema de arquivos, talvez seja necessário baixar ferramentas adicionais para extrair a imagem.
Se o binwalk não conseguir identificar o sistema de arquivos ou, em vez disso, identificar falsos positivos, também podemos tentar a análise manual. Discutiremos isso mais adiante neste artigo. Agora que temos o código e os binários que são executados no dispositivo, podemos começar a testar.
Ao executar o binwalk no firmware do JioFi 2, ele detecta muitos arquivos diretamente em texto simples, que não estão incluídos em um sistema de arquivos. Além disso, abra o arquivo do firmware em um editor hexadecimal e pesquise os primeiros bytes (também chamados de bytes mágicos). O arquivo será identificado como um FBF (Arquivo Binário Flash).
Caso isso não funcione, avaliaremos se o arquivo está criptografado usando a análise de entropia com `binwalk -E`.
À direita: análise de entropia do firmware de um sistema Sony Audio. Observe a baixa entropia no início e depois a entropia muito alta no resto do arquivo, o que indica uma parte do cabeçalho não criptografada, seguida por conteúdo criptografado
A presença de firmware criptografado geralmente significa que é difícil prosseguir. Nesse caso, pode-se tentar fazer engenharia reversa do cabeçalho para ver se os metadados de descriptografia (algoritmo chave) estão no cabeçalho. Isso é altamente improvável.
Se o firmware necessário não estiver disponível ou for impossível extrair qualquer coisa, há outras maneiras de proceder.
2. Exploração de serviços
Um dispositivo de IoT terá uma interface de rede. Assim, podemos iniciar o nmap e escanear o host em busca de serviços abertos.
Os roteadores, por exemplo, têm um servidor http com uma interface web para configuração, informações de status etc. que é um alvo fácil para bugs.
A vulnerabilidade mais importante a ser observada durante esses testes de caixa preta na interface do usuário da web é a injeção de comando. Muitas das funcionalidades da interface do usuário da Web são apenas um invólucro para utilitários internos do Linux, como iptables, ping, traceroute etc.
As ações na interface da web são passadas para esses utilitários como comandos de shell parametrizados normais, que podem levar à injeção de comandos se a entrada não for higienizada. Além disso, também devemos procurar a execução de ações não autenticadas ou se alguma das páginas falhou ao implementar verificações de autenticação.
Ilustração passo a passo
Aqui está uma dessas injeções que encontrei em um grande roteador emitido pelo ISP:
Depois que uma injeção de comando for executada, vamos escalá-la para um acesso completo ao shell. Normalmente, poderemos encontrar um binário telnet. Se não conseguirmos encontrar o binário no sistema, podemos fazer o download de um. Posteriormente, inicie um ouvinte telnet como este: `127.0.0.1 && /usr/sbin/utelnetd -l bin/sh -p 2512`.
Em seguida, exploramos os processos que estão em execução.
Todos esses arquivos e dados expandem a superfície de ataque. Esses binários e seus arquivos de configuração determinam se são ferramentas personalizadas ou prontas para uso. Podemos aproveitar kits de ferramentas de engenharia reversa, como o Ghidra, para analisar esses binários e verificar sua suscetibilidade a problemas de corrupção de memória, como estouro de buffer ou bugs lógicos.
Neste ponto, também podemos explorar o sistema de arquivos para arquivos de configuração ou realizar uma análise estática do código-fonte do backend da interface do usuário da web. Os bugs mais valiosos a serem procurados são os RCEs de pré-autenticação que podem ser explorados remotamente. Além disso, tente encontrar serviços que escutem na interface WAN e use-os para encontrar um bug.
Um dos bugs que encontrei, durante esse processo, foi uma escuta binária telnet na WAN que usava um executável/bin/ login personalizado que só funcionava se fornecido com uma senha codificada.
Essas vulnerabilidades simples não são muito raras. Os desenvolvedores geralmente deixam expostas as senhas de backdoor codificadas. Estes são alguns exemplos que provam o mesmo:
https://securityledger.com/2015/08/hardcoded-firmware-password-sinks-home-routers/
https://jalalsela.com/hacking-tp-link-tl-wr740n-backdoor/
Bugs de injeção de comando também são muito comuns:
https://www.cybersecurity-help.cz/vdb/SB2019040101
https://packetstormsecurity.com/files/145823/TP-Link-Remote-Command-Injection.html
Quando os desenvolvedores deixam as senhas padrão habilitadas nos dispositivos, os hackers nem precisam de vulnerabilidades para explorá-las. Aqui está uma lista de câmeras que ficaram expostas com as senhas padrão definidas:
https://www.shodan.io/explore/tag/camera.
Da mesma forma, podemos encontrar roteadores, impressoras, sistemas de segurança etc. com as senhas padrão ativadas.
3. Engajamento de hardware
Antecipando uma falha, para encontrar vulnerabilidades no firmware ou em qualquer outro serviço em execução com o teste de caixa preta, existem outras maneiras de detectar vulnerabilidades:
3.1 Interface serial
A maioria dos dispositivos de IoT executa um kernel Linux completo em uma caixa alimentada por MIPS ou ARM. Uma interface serial não é incomum nesses tipos de dispositivos.
Normalmente, é possível encontrar uma interface UART sobre RS-232 ou TTL no chip do dispositivo IoT. Uma interface RS-232 terá um conector de 9 pinos e uma interface TTL terá de 3 a 5 pinos. O chip, dentro da caixa externa, terá instruções sobre os conectores. Use um conversor USB-TTL, soldando a conexão entre o chip e o conversor.
Em seguida, conecte-se ao console serial e use as credenciais de administrador do dispositivo para fazer login.
Essas interfaces geralmente são fornecidas pelos fabricantes para remover o bloqueio do dispositivo. No momento da inicialização do dispositivo, temos acesso a funcionalidades adicionais, como carregar o firmware pela rede.
Depois que um prompt de shell é iniciado, podemos usar as técnicas discutidas anteriormente para testes adicionais.
3.2 JTAG
De qualquer forma, se o dispositivo não executar um sistema operacional completo ou o hardware não fornecer uma conexão serial, podemos tentar uma abordagem de nível ainda mais baixo.
O JTAG é outra interface de hardware comum que permite a comunicação direta com o microcontrolador em uma placa. Embora o JTAG tenha sido usado inicialmente pelos fabricantes para testar todas as conexões na placa, agora eles são usados para depuração de baixo nível.
As direções de conexão JTAG estão marcadas no chip. Caso contrário, a folha de especificações do microcontrolador/processador terá os mesmos detalhes. Solde diretamente nos pinos JTAG do microcontrolador para acessar a interface de depuração.
3.3 O que você pode fazer com o JTAG?
- Pausar e prosseguir com uma operação
- Inspecione a memória
- Escreva bytes diretamente na memória,
- Definir pontos de interrupção
- Injete código no processo ou na memória do processo
- Despejar o conteúdo do bootloader
- Ignorar logins e assim por diante
O que os hackers podem fazer depois de encontrar bugs nesses dispositivos?
O ataque do Mirai Botnet
Em 2016, vulnerabilidades de segurança em marcas de câmeras de segurança quase derrubaram a internet. A botnet Mirai lançou ataques distribuídos de negação de serviço de 623 Gbps em vários alvos. O tráfego se originou de milhares dessas câmeras de segurança. No ano seguinte, sua variante, Mirai Okiru, foi lançada, visando roteadores Huawei.
A proliferação de dispositivos de IoT tornou quase impossível lidar com o número crescente de ataques que eles enfrentam.
Invadindo a privacidade
A maioria dos dispositivos inteligentes é frequentemente explorada para invadir a privacidade de seus usuários:
- Os alto-falantes inteligentes são explorados para ouvir as interações.
- Dispositivos de segurança, como câmeras de CFTV, são usados de forma abusiva para obter acesso a imagens confidenciais.
- Vulnerabilidades em roteadores podem comprometer o tráfego da Internet. Os hackers podem ver os sites visitados por meio de consultas de DNS em texto simples. Além disso, eles podem realizar ataques MitM e roubar credenciais ou sessões. Essas vulnerabilidades também expõem os dispositivos internos ao invasor, contornando o firewall NAT e causando graves danos.
Inscreva-se nos recursos do CloudSEK
Receba as últimas notícias, ameaças e recursos do setor.
