O que aconteceu com a camera Hanwha
Uma camera de segurança fabricada pela Hanwha foi flagrada fazendo algo alarmante: ela incluía um token de administrador do GitHub diretamente no código HTML da sua própria página de login. Qualquer pessoa que abrisse o navegador, digitasse o IP do dispositivo e inspecionasse o código-fonte tinha acesso a essa credencial corporativa.
A descoberta foi publicada por um pesquisador de segurança que analisou o comportamento de rede da camera. O token encontrado era do tipo GitHub admin token, com permissões elevadas sobre repositórios da empresa. Isso significa que, na prática, qualquer pessoa na mesma rede que a camera poderia ter lido ou modificado código-fonte corporativo sem autorização.
A Hanwha e uma das maiores fabricantes de cameras de vigilância do mundo, com produtos vendidos para empresas, prédios, hospitais e órgãos governamentais. A gravidade do problema não esta só no bug em si, mas em quantos dispositivos potencialmente vulneráveis existem instalados por ai.
Como esse tipo de erro acontece
O problema e mais comum do que parece. Em muitos projetos de firmware para dispositivos IoT, o processo de build usa credenciais de CI/CD para baixar dependências privadas ou publicar versões. Quando essas credenciais ficam embutidas no código durante o processo de build, elas acabam indo para o binário final.
No caso da camera da Hanwha, o token foi parar no HTML da página de login provavelmente porque o frontend do painel de autenticação foi compilado com a variável de ambiente exposta. Em desenvolvimento isso seria um erro facilmente detectado, mas em ambientes de produção sem revisão de segurança adequada, esse tipo de dado vaza para o produto final.
Outro vetor comum: arquivos de configuração commitados no repositório com segredos embutidos, sem uso de variáveis de ambiente ou sistemas de secrets management. O desenvolvedor testa localmente com a chave real, commita sem perceber, e o CI/CD inclui essa chave no build e eventualmente no artefato publicado.
Token embutido em HTML de página pública e equivalente a colocar a chave de casa embaixo do tapete na porta da frente. Qualquer pessoa com acesso a rede pode ler.
O que um admin token do GitHub permite fazer
Tokens de administrador no GitHub tem permissões amplias. Dependendo do escopo configurado, um attacker com esse token poderia:
- Ler repositórios privados: acesso a código-fonte, segredos, chaves de API e dados confidenciais que estejam nos repos da organização.
- Escrever em repositórios: injetar código malicioso em qualquer branch, incluindo a branch principal de produção.
- Acessar Actions e Secrets: ver e modificar pipelines de CI/CD, potencialmente comprometendo todo o ciclo de deploy.
- Gerenciar membros e times: adicionar usuários, alterar permissões, expulsar membros da organização.
No caso específico da Hanwha, o escopo exato do token não foi divulgado, mas a classificação como admin token sugere permissões amplas. O impacto potencial ia muito além de ver o código.
Como verificar se um dispositivo IoT tem esse problema
Se você gerência cameras ou outros dispositivos IoT na sua infraestrutura, aqui esta um checklist rápido:
Passo 1: Abra a interface web do dispositivo e use o DevTools do navegador (F12) para inspecionar o HTML e as requisições de rede.
Passo 2: Procure por strings que se parecem com tokens (começam com ghp_, glpat-, sk-, etc.) nos scripts JS, meta tags, headers de resposta ou cookies.
Passo 3: Análise as requisições de rede feitas na inicialização. Dispositivos comprometidos frequentemente fazem chamadas externas revelando credenciais em headers ou query params.
# Verificar headers HTTP da interface do dispositivo
curl -v http://IP_DO_DISPOSITIVO/login 2>&1 | grep -iE "token|api_key|authorization|secret"Não faca isso em dispositivos de terceiros sem autorização. O procedimento e valido apenas para dispositivos que você gerência ou tem permissão explicita para auditar.
Comparação com outros incidentes similares
O caso Hanwha não e isolado. Vazamentos de credenciais em firmware e dispositivos conectados são um problema recorrente na industria:
- Roteadores com senhas hardcoded: múltiplos fabricantes (Netgear, D-Link) já foram pegos com credenciais de manutenção embutidas que não podiam ser alteradas pelo usuário.
- Smart TVs com tokens de API: pesquisadores já encontraram chaves de serviços de streaming e analytics embutidas em firmware de TVs de grandes marcas.
- Impressoras com credenciais LDAP: dispositivos corporativos com acesso ao Active Directory expondo credenciais de serviço no painel web.
O padrão e o mesmo: pressa no desenvolvimento, ausência de revisão de segurança no ciclo de build e ausência de ferramentas automáticas de detecção de secrets.
O GitHub Secret Scanning detecta tokens expostos em repos públicos e notifica automaticamente. Habilite também o Push Protection para bloquear commits com secrets antes que entrem no histórico.
Pontos positivos e limitações da divulgação responsável
A forma como essa vulnerabilidade foi divulgada importa. O pesquisador publicou os detalhes de forma pública, o que criou pressão para que a Hanwha corrigisse, mas também alertou possíveis atacantes antes de um patch estar disponível.
A divulgação responsável ideal envolve: (1) contatar o fabricante com os detalhes técnicos, (2) aguardar um prazo razoável para correção (geralmente 90 dias, padrão Google Project Zero), (3) só então publicar publicamente, preferencialmente junto com o anuncio do patch.
No mundo IoT, isso é ainda mais crítico porque muitos dispositivos nunca recebem atualizações de firmware, e quando recebem, os usuários raramente as aplicam. Um dispositivo vulnerável pode ficar exposto por anos após a divulgação.
Casos de uso reais onde esse risco aparece
Esse tipo de problema não afeta só fabricantes de hardware. Qualquer time de desenvolvimento pode cair na mesma armadilha:
- Apps mobile com chaves embutidas: tokens de Firebase, AWS ou serviços de pagamento embutidos no APK ou IPA, facilmente extraídos com ferramentas de reversão.
- Containers Docker públicos: imagens publicadas no Docker Hub com secrets no histórico de layers, recuperáveis mesmo após o commit de remoção.
- Repositórios públicos acidentais: repos criados como públicos por engano com arquivos de configuração contendo credenciais reais.
- Logs de CI/CD: pipelines que imprimem variáveis de ambiente em logs de build acessíveis por toda a organização.
Dicas e boas práticas para evitar esse problema
Use o git-secrets ou o detect-secrets como hook de pre-commit. Eles bloqueiam o commit se detectarem padrões de token, chave de API ou senha no código.
Para secrets em CI/CD, use sempre variáveis de ambiente injetadas pelo pipeline (GitHub Secrets, GitLab CI Variables, HashiCorp Vault). Nunca hardcode credentials em arquivos commitados.
Audite periodicamente seus repositórios com ferramentas como truffleHog ou gitleaks. Elas varrem o histórico de commits em busca de secrets que já foram removidos mas ainda existem em commits antigos.
Se um secret foi commitado em um repo, remover o arquivo não e suficiente. O secret ainda existe no histórico de git. Use git-filter-repo para reescrever o histórico e revogue o token imediatamente.
Vale a pena se preocupar com isso?
Sim, e muito. Secrets expostos em código são uma das causas mais comuns de brechas de segurança em empresas de tecnologia. O custo de prevenção (ferramentas de detecção no pipeline, cultura de não commitar secrets) e ordens de magnitude menor do que o custo de uma brecha real.
Para times de desenvolvimento, o primeiro passo e habilitar o Secret Scanning do GitHub (gratuito em repos públicos, disponível em planos pagos para repos privados) e adicionar um hook de pre-commit com detect-secrets. São dois passos de menos de 30 minutos que eliminam a grande maioria dos riscos.
Para quem gerência infraestrutura IoT, o caso Hanwha e um lembrete de fazer auditorias periódicas nos painéis web dos dispositivos instalados. Um attacker na mesma rede de um dispositivo comprometido tem acesso potencial a muito mais do que só a camera.
Comentários
Deixar um comentárioVocê precisa ter uma conta no CuritibaBlog para comentar.