Sua Câmera de Segurança Vazou um Token Admin do GitHub na Página de Login

Você compra uma câmera de segurança pensando em proteger sua casa. Instala, configura, aponta pro portão. O que você não espera é que essa mesma câmera esteja vazando credenciais de administrador do GitHub para qualquer um que abra a interface web. Mas foi exatamente isso que aconteceu com as câmeras da Hanwha Vision, a mesma empresa que fabricava câmeras Samsung.

Um pesquisador de segurança baixou o firmware de uma câmera Hanwha Wisenet, descriptografou o conteúdo (usando uma chave que qualquer um pode adivinhar), rodou um scanner de credenciais e encontrou um token GitHub com privilégios de administrador em centenas de repositórios internos da empresa. O token estava lá, aberto, dentro dos arquivos da interface web da câmera. Em pelo menos 3 versões de firmware. Todas usando o mesmo token.

Eu já vi muita bobagem em IoT, mas essa é especialmente criativa.

Como o pesquisador encontrou o token

A Hanwha Vision disponibiliza blobs de firmware no site de suporte. Cada modelo de câmera tem seu próprio pacote. O pesquisador baixou vários deles e percebeu que todos seguiam um padrão de criptografia previsível.

A chave de descriptografia? HTW + o número do modelo. Literalmente. Se sua câmera é o modelo XNV-6120, a senha é HTWXNV6120. Isso não é segurança, é um post-it colado no monitor.

Com o firmware aberto, ele extraiu o rootfs (o sistema de arquivos raiz) e rodou ferramentas como trufflehog e gitleaks para procurar segredos expostos. O resultado: um token do GitHub com permissões de administrador apareceu em aproximadamente 30 arquivos dentro dos artefatos de build da interface web.

# Exemplo simplificado do processo de descoberta
# 1. Baixar firmware do site da Hanwha
wget https://support.hanwhavision.com/firmware/XNV-6120_v2.41.zip

# 2. Extrair e descriptografar
unzip XNV-6120_v2.41.zip
# A chave de descriptografia é trivial: HTW + modelo

# 3. Montar o rootfs extraído
binwalk -e firmware.bin

# 4. Escanear por segredos
trufflehog filesystem ./rootfs --only-verified
gitleaks detect --source ./rootfs

O problema está no Vite (e no CI/CD descuidado)

A interface web dessas câmeras é um frontend moderno construído com Vite. Até aí, normal. O problema é que durante o build no CI/CD, o processo do Vite capturou todas as variáveis de ambiente do job de compilação e gravou dentro do código compilado.

Isso significa que tudo que existia no ambiente de CI naquele momento foi parar dentro do firmware: tokens, URLs internas, variáveis de configuração. E como o firmware é distribuído para cada câmera vendida, qualquer pessoa com acesso ao painel de administração da câmera poderia potencialmente ver essas informações.

Pra quem trabalha com frontend, isso é um lembrete importante. O Vite (e o Webpack, e qualquer bundler moderno) pode expor variáveis de ambiente no bundle final. O Vite, por padrão, só expõe variáveis prefixadas com VITE_, mas outras ferramentas e plugins podem mudar esse comportamento. Se o seu pipeline de CI/CD injeta segredos como variáveis de ambiente, eles podem acabar no bundle.

// O que provavelmente aconteceu no build da Hanwha
// O Vite capturou process.env inteiro durante o build
// e embedou no código final

// vite.config.js (configuração perigosa)
export default defineConfig({
  define: {
    'process.env': JSON.stringify(process.env)
    // NUNCA faça isso. Nunca.
  }
})

// Configuração segura
export default defineConfig({
  // Vite só expõe VITE_* por padrão
  // Não override esse comportamento
})

Endereços IP do Departamento de Defesa dos EUA

Aqui é onde a história fica estranha. Entre as variáveis de ambiente vazadas, o pesquisador encontrou endereços IP pertencentes ao Departamento de Defesa dos Estados Unidos. Não IPs aleatórios: blocos de endereços designados ao DoD.

A explicação mais provável (e menos cinematográfica) é que a Hanwha Vision compartilha infraestrutura de CI/CD com suas empresas irmãs focadas em defesa. A Hanwha é um conglomerado sul-coreano com divisões que fabricam desde câmeras de segurança até sistemas de artilharia. Se o mesmo pipeline de build serve múltiplas divisões, é perfeitamente possível que endereços de redes internas de projetos de defesa apareçam nas variáveis de ambiente.

Isso não torna a situação menos grave. Se um CI compartilhado está vazando dados entre divisões, o problema é de compartimentalização. E se esses dados acabam em firmware público, é uma falha de segurança operacional séria, independente de haver ou não conexão direta com sistemas militares.

O token tinha acesso admin a centenas de repositórios

O token não era um token de leitura com escopo limitado. Era um token com privilégios de administrador que dava acesso a centenas de repositórios da organização Hanwha no GitHub. Com esse token, alguém poderia:

• Ler todo o código-fonte dos produtos da Hanwha Vision
• Modificar código em repositórios de produção
• Acessar secrets armazenados no GitHub Actions
• Criar releases com código malicioso
• Deletar branches, tags e histórico

Na prática, era um acesso irrestrito ao coração do desenvolvimento de software da empresa. E estava disponível para qualquer um que comprasse uma câmera de R$ 2.000 e soubesse onde procurar.

O mais preocupante é que o token apareceu em pelo menos 3 das ~500 versões de firmware analisadas, e todas as 3 usavam exatamente o mesmo token. Isso sugere que ninguém rotacionava essa credencial. O mesmo token, com acesso admin, existia há tempo suficiente para ser embedado em múltiplas releases.

Timeline: da descoberta à correção

O pesquisador seguiu o processo de responsible disclosure:

1. Descoberta: análise de firmware revela o token
2. Contato: envio para o e-mail de segurança da Hanwha Vision
3. Resposta: token revogado em menos de 12 horas
4. Correção: Hanwha anunciou atualização de firmware com verificação de assinatura digital

Doze horas para revogar um token é uma resposta razoavelmente rápida. Mas a pergunta real é: por quanto tempo esse token ficou exposto antes de alguém olhar?

Considerando que as versões de firmware afetadas já estavam disponíveis no site de suporte, qualquer pessoa com conhecimento técnico básico poderia ter encontrado o token antes do pesquisador. E não temos como saber se alguém já o usou.

O elefante na sala: a criptografia do firmware

A Hanwha usa “criptografia” nos seus arquivos de firmware. As aspas são propositais. A chave é literalmente o prefixo HTW concatenado com o número do modelo da câmera. Qualquer um que saiba o modelo (que está impresso na etiqueta do produto) pode descriptografar o firmware.

Isso não é security through obscurity. É a versão piorada: security through a senha que está colada na embalagem.

Depois da divulgação, a Hanwha anunciou que vai implementar verificação de assinatura digital nos firmwares. Isso significa que a câmera vai rejeitar firmwares não assinados pela Hanwha, mas não resolve o problema de alguém extrair e analisar o conteúdo. O que muda é que atacantes não poderão instalar firmwares modificados nas câmeras, mas ainda poderão ler tudo que está dentro do firmware legítimo.

# Verificação de firmware (como deveria funcionar)
# A câmera verifica a assinatura antes de aplicar o update
openssl dgst -sha256 -verify hanwha_public.pem \
  -signature firmware.sig firmware.bin

# Se a assinatura não bate, o firmware é rejeitado
# Mas isso não impede alguém de ANALISAR o conteúdo

O que isso ensina sobre segurança em IoT

Essa história não é única. Eu já perdi a conta de quantas vezes credenciais apareceram em firmware de IoT. Mas ela ilustra três problemas sistêmicos:

1. CI/CD sem isolamento

Pipelines de build devem ter acesso mínimo. O job que compila o frontend de uma câmera não precisa de um token GitHub admin. Na verdade, ele provavelmente não precisa de token nenhum do GitHub. O princípio do mínimo privilégio existe por um motivo, e a maioria das empresas de IoT parece não ter ouvido falar dele.

# GitHub Actions: exemplo de como NÃO configurar
jobs:
  build-camera-ui:
    runs-on: ubuntu-latest
    env:
      GITHUB_TOKEN: ${{ secrets.ADMIN_TOKEN }}  # NÃO
      # Use um token com escopo mínimo
      # Ou melhor: não use token nenhum para builds de frontend

# Como deveria ser
jobs:
  build-camera-ui:
    runs-on: ubuntu-latest
    # Sem tokens desnecessários
    # Se precisar de dependências privadas, use um token read-only
    # com escopo apenas para os repos necessários

2. Bundlers que vazam segredos

O Vite faz um bom trabalho por padrão: só expõe variáveis prefixadas com VITE_. Mas desenvolvedores podem (e fazem) sobrescrever esse comportamento. Ou usar plugins que expõem process.env inteiro. Ou configurar o define de forma descuidada.

A lição aqui é simples: trate o output do seu bundler como público. Porque, no caso de uma câmera de segurança, ele literalmente é.

3. “Criptografia” de firmware como teatro

Criptografar firmware com uma chave derivada do número do modelo é o equivalente a trancar a porta e deixar a chave debaixo do tapete. Todo mundo sabe onde está. A motivação geralmente é impedir engenharia reversa casual, mas qualquer atacante motivado vai passar por cima disso em minutos.

Se você precisa proteger segredos no firmware (spoiler: você não deveria ter segredos no firmware), use criptografia real com chaves que não sejam públicas. Ou, melhor ainda, redesenhe seu sistema para que o firmware não contenha segredos.

Como proteger suas câmeras (já que o fabricante não protege)

A discussão no Hacker News gerou recomendações práticas que valem mais que o manual da câmera:

• VLAN separada: coloque todas as câmeras em uma rede isolada, sem acesso à internet. Use um NVR local ou software como o Frigate para gravar e acessar as imagens.
• Bloqueie tráfego outbound: se a câmera não precisa da internet (e não deveria precisar), bloqueie no firewall. Muitas câmeras tentam se conectar a servidores na China sem motivo aparente.
• Considere firmware aberto: projetos como OpenIPC oferecem firmware open source para câmeras compatíveis. Você perde o suporte do fabricante, mas ganha transparência.
• Monitore o tráfego: rode um IDS como o Suricata na rede das câmeras. Se alguma delas começar a enviar dados para IPs estranhos, você vai saber.

# Configuração básica de firewall para câmeras IP
# (exemplo com iptables no roteador/firewall)

# Rede das câmeras: 192.168.10.0/24
# NVR/Frigate: 192.168.1.100

# Permite câmeras falarem com o NVR
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.1.100 -j ACCEPT

# Bloqueia todo o resto (incluindo internet)
iptables -A FORWARD -s 192.168.10.0/24 -j DROP

# Permite NVR acessar câmeras
iptables -A FORWARD -s 192.168.1.100 -d 192.168.10.0/24 -j ACCEPT

O padrão se repete: IoT e a falta de accountability

A Hanwha respondeu rápido, e isso é bom. Mas a realidade é que a maioria dos fabricantes de IoT opera com zero accountability em segurança. Não existe uma FDA para dispositivos conectados. Não existe recall obrigatório quando um firmware vaza credenciais. O máximo que acontece é um pesquisador postar no blog, viralizar no Hacker News, e a empresa correr pra tapar o buraco.

No HN, vários comentários apontaram que a solução real é usar câmeras com firmware open source, isoladas em VLANs, com gravação local. Não porque os fabricantes são maliciosos, mas porque a cadeia de qualidade simplesmente não existe. A pressão por custo baixo e time-to-market rápido joga segurança pra debaixo do tapete.

E o mais irônico? Estamos falando de câmeras de segurança. O dispositivo que deveria proteger seu patrimônio é o mesmo que está servindo tokens admin do GitHub para qualquer um que saiba fazer um binwalk.

Se você tem câmeras Hanwha Wisenet, atualize o firmware agora. Se você tem câmeras de qualquer fabricante, isole na rede. Se você trabalha com IoT, audite seu pipeline de CI/CD hoje. Aquele process.env no seu bundle pode ser a próxima notícia no Hacker News.

Fonte de inspiração: My security camera shipped a GitHub admin token in its login page