tothi/pwn-hisilicon-dvrProva de conceito de exploit e divulgação de vulnerabilidades para dispositivos DVR/NVR HiSilicon hi3520d. Demonstra RCE via interface web, credenciais de backdoor e análise de buffer overflow.
= Hack de DVR HiSilicon Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Conteúdo :image_width: 100%
[abstract] Este relatório divulga vulnerabilidades graves (com código de prova de conceito (PoC)) de dispositivos DVR/NVR construídos com o HiSilicon hi3520d e system-on-a-chip (SoC) similares. A exploração das vulnerabilidades leva à execução remota de código (RCE) não autorizada usando apenas a interface web, causando a assunção total do dispositivo explorado. Devido à falta de firmwares atualizados, não é recomendado utilizar esses dispositivos. O fornecedor foi contactado antes de dezembro de 2016, mas ainda não houve resposta. A data de divulgação do comunicado é fevereiro de 2017.
== prefácio
Há alguns anos, comprei um dispositivo DVR chinês barato no eBay. O logotipo de inicialização do dispositivo diz: "SECULINK - Security Monitoring". Como entusiasta de segurança de TI, decidi analisar mais de perto o dispositivo para ver quão "seguro" é esse serviço de monitoramento de segurança. Pesquisando no Google sobre o assunto, encontrei alguns materiais interessantes, mas fui mais fundo e encontrei problemas muito mais interessantes e muito mais sérios (0-days) sobre o dispositivo.
Vamos dar uma olhada na sessão completa de hacking desde o início. (As novas conquistas próprias serão observadas, assim como as antigas e conhecidas.)
== explorando o DVR
Primeiro devemos aprender a interface oficial do usuário, depois aprofundar, talvez tentar obter o firmware. As chances de encontrar vulnerabilidades aumentam com o firmware.
=== o DVR à primeira vista
O dispositivo DVR destinado a testes tem a marca "Seculink".
image::./seculink_device.png[Dispositivo DVR Seculink]
Interfaces físicas disponíveis:
Interfaces oficiais do usuário:
A interface de configuração diretamente acessível é restrita por autenticação de usuário (nome de usuário, senha). O superusuário padrão é 'admin', a senha padrão é vazia.
Após definir uma senha forte, o usuário pode se sentir seguro de que a visualização de suas câmeras não é acessível por outras pessoas. As pessoas frequentemente encaminham a porta web (tcp/80) do dispositivo DVR para o lado WAN a partir de sua LAN segura para acessar os fluxos do DVR de fora (podemos verificar isso, por exemplo, com uma busca adequada no Shodan ;) ).
=== obtendo o firmware
Pode haver muitas maneiras de obter o firmware:
Embora o último método (download) funcione aqui e seja o mais fácil, vamos tentar o primeiro, porque ele também fornece outras informações sobre o dispositivo.
=== varredura de serviços
Vamos fazer uma varredura completa de portas no DVR. Observe que a varredura SYN (padrão se executada como root) é muito lenta devido a pacotes descartados, mas a varredura completa de conexão TCP termina em alguns minutos.
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
Resumindo e testando manualmente:
Observe que abrir o fluxo rtsp também requer credenciais.
Aqui devemos afirmar que o dispositivo é provavelmente algum sistema tipo Linux.
Conectar-se a 9527/tcp (via netcat puro) mostra o console do aplicativo
com mensagens de log e um prompt de login. Entrar com qualquer uma das
credenciais definidas do aplicativo funciona. Executar help após o
prompt dá uma descrição curta dos comandos do console. O comando
shell parece ser o mais interessante. Sim, ele dá um shell root para
os dispositivos. ;)
Observe que isso é obviamente um grave problema de segurança, porque nenhum usuário do aplicativo (com privilégios baixos) deveria obter um shell root no dispositivo automaticamente.
=== shell root
Explorando o dispositivo no shell root (por exemplo, com dmesg), fica
evidente que o DVR está executando um kernel Linux (versão 3.0.8), tem
uma CPU ARMv7, o modelo do SoC é hi3520d.
Pela lista de processos em execução (ps), fica claro que o aplicativo
DVR é /var/Sofia, que também está escutando em 34568/udp e
34569/udp, além das portas tcp acima detectadas pelo nmap
(netstat -nlup).
Pela lista de discos montados (comando mount), fica claro que a
imagem do firmware está nos dispositivos /dev/mtdblockX (onde X=0,1,2,3,4,5).
O firmware é pequeno e, portanto, limitado, então devemos ser criativos se quisermos copiar arquivos para/de o dispositivo. Felizmente, o NFS é suportado, então configurar um servidor NFS em nossa máquina desktop e montá-lo a partir do DVR resolve o problema:
Agora obter o firmware é simples:
Podemos obter os arquivos (não apenas as imagens brutas):
=== interface telnet
Para acessar o dispositivo através da interface telnet (porta 23/tcp),
podemos precisar de algumas credenciais do SO. Olhando em /etc/passwd, temos o
hash da senha do usuário root:
Observe que não há outro usuário além de root, tudo está rodando com privilégios totais. (Então, se alguém invadir o dispositivo de alguma forma, não há barreira, o invasor ganha poder total imediatamente.)
Assumindo uma senha alfanumérica de seis caracteres (minúsculas), o hashcat quebra o hash DES fraco acima rapidamente:
$ ./hashcat64.bin -a3 -m1500 absxcfbgXtb3o -1 ?l?d ?1?1?1?1?1?1
