Página de login da UI web de câmeras de segurança da Hanwha Vision foi distribuída com token de administrador do GitHub

 (hhh.hn)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Cerca de 30 arquivos da UI de administração web do firmware de câmeras Hanwha Vision continham o mesmo token do GitHub, que tinha permissões de administrador em centenas de repositórios da organização
  • O fwupgrader do firmware reconstruía uma chave AES hardcoded aplicando XOR com uma tabela estática e depois descriptografava o sistema de arquivos raiz com openssl; a chave e o IV eram compartilhados pela mesma família de modelos
  • Como uma variável de build do Vite foi configurada como todo o process.env, variáveis de ambiente do job de CI foram gravadas no artefato, e o GITHUB_NPM_TOKEN junto com várias configurações internas acabaram incluídos no firmware da câmera
  • Cerca de 500 firmwares foram analisados da mesma forma, com 62% extraídos; os 3 firmwares em que o token do GitHub foi encontrado continham todos o mesmo token
  • A Hanwha revogou o token em até 12 horas após a denúncia, mas uma configuração que insere todo o ambiente de CI no artefato cliente pode expor credenciais e informações de infraestrutura interna nos produtos

Obtenção do firmware e a primeira camada de criptografia

  • O site da Hanwha Vision disponibilizava imagens de firmware por modelo de câmera, permitindo baixar os arquivos para análise
  • Ao examinar a imagem com binwalk, foram encontrados um tarball separado com componentes de IA para a câmera e um fwimage.tgz criptografado
  • Seguindo a análise de descriptografia de firmware Hanwha de Matt Brown, foi usada uma senha combinando HTW e o número do modelo
    • No alvo analisado, HTWXNP-9300RW funcionou
  • Dentro do tarball extraído havia outro fwimage.tgz criptografado de uma forma diferente, de modo que o procedimento de descriptografia existente não podia ser reutilizado diretamente

Reconstrução do método de descriptografia no fwupgrader

  • O binário fwupgrader incluído no tarball externo foi analisado com Ghidra e Claude Code para extrair o sistema de arquivos raiz real
  • O fwupgrader tinha ofuscação aplicada para esconder o método de descriptografia
    • A chave AES era combinada com uma pequena tabela estática de chaves dentro do binário usando XOR e então remontada em tempo de execução
    • O IV estava em texto claro no binário
    • Fragmentos do comando openssl também estavam ofuscados com XOR da mesma forma
  • O comando reconstruído tinha a seguinte forma, usando SHA-256 e AES-256-CBC 
    openssl enc -md sha256 -aes-256-cbc -d \  
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
  • A chave e o IV estavam hardcoded e eram compartilhados pela mesma família de modelos 
    KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0  
IV  = 53f926801b81454a4f889c9a390db6e6

Token de administrador do GitHub incluído no firmware

  • Ao inspecionar o sistema de arquivos raiz extraído com trufflehog, o mesmo token do GitHub foi encontrado repetidamente em cerca de 30 arquivos
  • Esse token tinha permissões de administrador em centenas de repositórios pertencentes à organização da Hanwha no GitHub
  • A UI da câmera é construída com Vite, e foi confirmado que uma variável de build estava configurada como todo o process.env, fazendo com que todo o ambiente do job de CI fosse gravado nos arquivos resultantes 
    var W = {  
  DATAPORT: "9090",  
  GIT_LFS_SKIP_SMUDGE: "1",  
  npm_command: "run-script",  
  KUBERNETES_SERVICE_PORT_HTTPS: "443",  
  GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",  
  npm_config_userconfig: "/home/docker/.npmrc",  
  // etc  
}
  • Sem uma câmera real, não foi possível verificar se isso funcionava na prática
    • É possível que o token tenha sido transmitido pela rede a usuários que acessassem a UI de administração
    • Também permanece a possibilidade de o arquivo existir apenas no disco e não ser realmente servido

Endereços do DoD incluídos no ambiente de CI

  • As variáveis de ambiente expostas também incluíam endereços IP alocados ao Departamento de Defesa dos EUA
  • Não foi confirmado se esses endereços foram usados arbitrariamente em serviços internos que não se comunicam externamente, ou se decorrem de uma relação entre a Hanwha e o Departamento de Defesa dos EUA
  • A Hanwha Vision é uma empresa de vigilância por vídeo fundada como Samsung Techwin e subsidiária do Hanwha Group
    • Produtos anteriores incluem o obuseiro autopropulsado K9 Thunder, o veículo blindado de transporte de munição K10, subsistemas do K2 Black Panther e o robô de vigilância SGR-A1
    • O SGR-A1 é um robô de vigilância armado
  • É possível que o CI fosse fornecido pela organização central da Hanwha e que variáveis relacionadas fossem compartilhadas por exigência da afiliada Hanwha Aerospace ou da Hanwha Defense USA, mas isso é uma especulação não confirmada

Investigação de todo o firmware

  • Para verificar se era um caso isolado acidental ou se havia outros tokens diferentes, foram coletados firmwares de câmeras disponíveis para download no site da Hanwha
  • Entre cerca de 600 câmeras, foram obtidos cerca de 500 firmwares para modelos que disponibilizavam firmware
  • Usando o mesmo método, 62% puderam ser extraídos; não foi possível determinar por que os demais falharam
  • Havia 3 firmwares contendo o token do GitHub, e todos incluíam o mesmo token

Denúncia e resposta

  • Foram enviadas informações mínimas suficientes para identificar a localização do token ao e-mail público de denúncias de segurança da Hanwha
  • A Hanwha respondeu em até 12 horas após a denúncia e revogou o token em questão
  • Embora incluir um token do GitHub no firmware seja um erro, o recebimento da denúncia e a correção ocorreram muito rapidamente

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Estou procurando uma câmera IP white-label ou um produto quase plug-and-play em que o fabricante dê suporte, mas permita remover o rootfs quando necessário
    Antigamente só existiam kits de desenvolvimento caros, sem nem mesmo um gabinete, mas agora parece haver opções como a GoodCam

    • Mesmo sem firmware aberto, usar ONVIF em uma rede isolada chega bem perto disso
      Câmeras ONVIF são compatíveis com a maioria dos gravadores de vídeo em rede (NVR), e também existem vários NVRs open source
      Se você não expuser câmeras PoE baratas à internet, a segurança do firmware do fabricante importa menos, mas VLAN e segmentação de rede precisam ser configuradas com muito cuidado
    • Criei o Wyrecam para resolver esse problema, e ele suporta o Ingenic T31 do Wyze v3
      A estabilidade é parecida com a do Apple HomeKit, ou seja, não muito boa
    • O Thingino deixa clara a lista de câmeras compatíveis, e a instalação é simples se o modelo suportar gravação via cartão SD
      Atualizei dois Sonoff Slim Gen2 sem problemas
    • Em algumas câmeras, o Thingino pode substituir o firmware existente, e a lista de hardware compatível com OpenIPC também vale a consulta
    • A página da loja parece não funcionar, mostrando erros como Stránka nenalezena e There's been a glitch...

  • Parece que o problema maior é o firmware ter um endereço IP do Departamento de Defesa dos EUA embutido, e isso me faz querer evitar produtos de segurança feitos na Coreia

    • Algumas empresas fazem blackhole de toda a faixa de IP do Departamento de Defesa dos EUA e a usam internamente, então pode ser isso, mas ainda assim é muito estranho
    • A Marinha do Canadá também parece ter tomado recentemente uma decisão parecida em um grande projeto: resultados de busca
    • O Departamento de Defesa dos EUA tem um espaço de endereços IP tão grande que também é bem possível ter sido coincidência
    • O mesmo vale para produtos IoT coreanos, e os mecanismos de segurança dos produtos com que lidei diretamente eram de um nível absurdo de ruim
    • Produtos nacionais também muitas vezes são uma bagunça, cheios de vulnerabilidades e engenharia relaxada

  • Muitos fornecedores usam padrões perigosos, segurança quebrada e valores hardcoded
    Mesmo que segurança não seja a prioridade máxima, pelo menos verificações básicas como checagem de credenciais hardcoded são necessárias

    • É irônico que, em câmeras de segurança, segurança não seja uma prioridade
    • Em um modelo operacional que entrega o trabalho para a mão de obra mais inexperiente e barata, é difícil esperar sequer verificações mínimas de padrão
    • Hoje em dia basta adicionar ao repositório recursos que façam verificações básicas de segurança, então quase não há desculpa

  • O mínimo é colocar as câmeras em uma VLAN separada e bloquear completamente o acesso dessa VLAN à internet

  • Uma vez verifiquei que muitos dongles OBD-II eram enviados com o mesmo endereço MAC, e como resultado era possível acessar todas as informações em vários sites
    Esse tipo de problema continua acontecendo mesmo quando se tenta evitar

    • Fico curioso sobre como o mesmo endereço MAC levou a acesso total
      Se o site usava o endereço MAC fornecido pelo cliente como método de autenticação, isso é um fracasso clássico de segurança em IoT

  • Talvez fosse melhor tirar segurança do nome do produto e chamar simplesmente de câmera

  • Me incomoda que este blog use errado o ícone de link externo

    • O seletor a[href*="://"]::after assume que links internos usam caminhos relativos como href="/about", mas este site usa URLs absolutas até nos links de navegação, como [https://hhh.hn/about](https://hhh.hn/about), então o ícone aparece em todos os links
      Dá para resolver excluindo links que começam com o endereço do site: a[href*="://"]:not([href^="https://hhh.hn";])::after

  • Uma luz ambiente interna que comprei recentemente não podia ser controlada sem o app dedicado
    Baixei o APK da Google Store e analisei, e as chaves de API do backend e até do Shopify estavam praticamente expostas, embora eu ainda não tenha feito nada com isso

    • Chaves públicas muitas vezes não concedem privilégios especiais
      Um desenvolvedor preocupado com segurança usaria App Attest ou o recurso equivalente da Google Store
    • Não consigo pensar em um motivo legítimo para um app de iluminação precisar de acesso à API do Shopify
      Dito isso, pela minha experiência com consultoria para lojas Shopify, a qualidade do código entregue por consultores ou designers baratos muitas vezes é tão ruim que isso não surpreende
    • Por segurança, vale comprar apenas dispositivos inteligentes com controle local, como Zigbee ou Z-Wave, mesmo que nem sempre sejam a melhor opção em aparência
    • Divulgar esse tipo de informação pode ser arriscado, porque a empresa pode reagir judicialmente
      Havia uma empresa que protegia pesquisadores contra consequências legais, mas não lembro o nome
    • No fim das contas dá para controlar mesmo sem o app dedicado, então espero que alguém faça engenharia reversa do protocolo e publique como

  • Por causa dos LLMs, a ofuscação de código ficou praticamente inútil
    A ofuscação só atrapalhava ao tornar o trabalho tedioso, mas a IA não se importa com esse esforço

    • A ofuscação só funcionava contra atacantes superficiais que não aguentavam o tédio
      Organizações estatais ou grupos criminosos de hackers encaram facilmente esse esforço
    • Pelo lado positivo, até um pequeno LLM local pode melhorar facilmente esse tipo de código de baixa qualidade

  • Já vi esse tipo de sistema em uma feira da indústria de defesa dos EUA, então é bem possível que esteja realmente em uso em algum lugar