Resumo
Uma bolsa de criptografia identificada como NCX supostamente deixou uma instância interna do MongoDB exposta na Internet pública sem autenticação. O banco de dados ficou acessível por meses, continha cerca de 1 GB de dados e mais de 5 milhões de registros, e incluía nomes, e-mails, datas de nascimento, links de documentos KYC, senhas com hash, sementes/URLs 2FA, chaves internas de API, histórico de IP, endereços de carteiras de contas e registros de transações.Análise diária de segurança) Não se trata apenas de "vazamento de PII". É uma superfície de comprometimento de pilha completa: roubo de identidade, fraude KYC, aquisição de conta, direcionamento na cadeia, exposição regulatória e obrigações de resposta a incidentes de acordo com os modernos regimes de proteção de dados que exigem divulgação em 72 horas.(GDPR)

Este artigo aborda a violação no estilo NCX de dois ângulos:

1. Testes ofensivos / realidade da equipe vermelha - como essa configuração incorreta se transforma em exploração ativa.
2. Conformidade e resposta - o que você deve fazer quando souber que perdeu o controle dos dados de identidade do cliente e dos segredos multifatoriais.

Também mapearemos como uma plataforma de testes ofensivos contínuos, como a Penligent, pode revelar e simular esses modos de falha exatos antes que um regulador, invasor ou jornalista o faça.

Visão geral do incidente: O que vazou e por que é importante

O problema relatado é simples em termos de fraseologia e brutal em termos de consequências: uma instância do MongoDB voltada para a Internet sem autenticação. Qualquer pessoa que soubesse (ou pudesse adivinhar/analisar) o IP e a porta poderia navegar pelas coleções em texto simples.Análise diária de segurança)

Tipos de dados expostos

De acordo com a divulgação, o conjunto de dados NCX continha (por registro, mais de milhões de linhas):

• Nome completo / e-mail / data de nascimento
• Imagem KYC ou links de documentos (passaporte, digitalizações de identidade)
• Valores de semente 2FA e URLs de registro
• Senhas com hash
• Histórico de endereços IP e metadados de login
• Chaves de API internas / tokens de serviço
• Endereços de carteiras, histórico de depósitos/retiradas, atividade em cadeia
• Sinalizadores de status da conta (proibição/congelamento/risco)
• Registros de tíquetes de suporte

Isso é excepcionalmente ruim por três motivos:

1. Aquisição de identidade em escala
   Se um invasor tiver seu nome legal + DoB + imagem do passaporte, ele poderá abrir contas em outro lugar, fazer engenharia social para "recuperação de conta" ou passar o KYC em locais mais fracos. Essa é a alavancagem do roubo de identidade.Análise diária de segurança)
2. Contorno de MFA por meio de exposição de sementes 2FA
   Se as sementes de senha única baseada em tempo (TOTP) forem armazenadas e vazadas, um invasor poderá gerar códigos válidos de 2FA sob demanda e fazer login como você, mesmo que você nunca tenha compartilhado sua senha. Sementes de 2FA comprometidas são essencialmente "tokens de sessão pré-criados".Análise diária de segurança)
3. Custódia + direcionamento na cadeia
   Os endereços de carteiras e os históricos de transações permitem que um adversário mapeie quais usuários realmente movimentam dinheiro. Esses alvos de alto valor podem então ser alvo de phishing ("Seu saque está bloqueado, assine aqui") ou de troca de SIM. Vimos plataformas de criptografia avisarem os usuários violados para esperar phishing personalizado usando exatamente esse manual.Análise diária de segurança)

Problema de ausência de resposta

Os pesquisadores que descobriram o MongoDB aberto tentaram a divulgação responsável várias vezes e não receberam uma resposta em tempo hábil.Análise diária de segurança)
Do ponto de vista regulatório, isso é catastrófico: Os regimes da classe GDPR e muitas autoridades nacionais de proteção de dados esperam contenção rápida, preservação de evidências, notificação de violação aos reguladores em 72 horas e, em muitos casos, notificação do usuário se o risco para os usuários for alto.GDPR)

Cadeia de ataques: como uma equipe vermelha transforma o "Open MongoDB" em comprometimento total da conta

Esta seção foi escrita como uma narrativa de teste de penetração, porque é assim que um invasor (ou um testador responsável) a percorreria.

Etapa 1: Enumeração do MongoDB exposto

• Faça a varredura de portas em amplas faixas do espaço de endereços da nuvem em busca de portas clássicas do MongoDB (27017/27018).
• Pegue o status do banner/servidor para confirmar o acesso não autenticado.
• Listar bancos de dados e coleções (db.getCollectionNames() etc.).
• Despeje coleções de alto valor: usuários, autenticação, kyc, carteira, transações, Chaves da API, bilhetes.

Em outras palavras, isso não é "0-day". Trata-se de uma configuração incorreta no nível dos anos 90: banco de dados na Internet, sem autenticação, sem firewall. A CISA e o NIST alertam repetidamente que os bancos de dados expostos à Internet sem autenticação continuam sendo um dos pontos de entrada de violação mais comuns.Comissão Europeia)

Aqui está uma pseudo-sessão simplificada que um invasor pode executar em uma caixa de teste (não execute isso em sistemas que você não possui ou tem permissão para avaliar; realizar acesso não autorizado é ilegal):

# Descubra os hosts MongoDB abertos (somente lógica de exemplo)
nmap -p 27017 --open  -oG mongo_hosts.txt

# Conectar-se a um host descoberto sem credenciais
mongosh --host :27017 --eval "db.adminCommand('listDatabases')"

# Enumerar coleções em um banco de dados de destino
mongosh --host :27017 --eval "use ncx_users; db.getCollectionNames()"

# Despejar documentos relacionados ao usuário
mongosh --host :27017 --eval "use ncx_users; db.users.find().limit(5).pretty()"

Para uma equipe vermelha de verdade, isso é o que está em jogo. Para um regulador ou advogado do autor da ação, isso é uma prova contundente de que o sistema não tinha "nenhum controle de segurança razoável".

Etapa 2: coletar segredos e material de autenticação

Uma vez dentro, o atacante puxa:

• senha_hash ou equivalente
• totp_seed / 2fa_secret
• chave api / api_secret
• URLs de arquivos KYC

Este é o prêmio principal. Os hashes de senha podem ser quebrados off-line; as sementes TOTP permitem que você cunhe códigos MFA válidos; as chaves de API podem se comunicar com o administrador interno ou back-ends de negociação.

Os pesquisadores de segurança e as equipes de DFIR observaram repetidamente que as sementes de 2FA vazadas e as credenciais de API "reutilizáveis" são saques de alto valor porque se transformam em aquisição direta de contas e movimento lateral.Análise diária de segurança)

Etapa 3: Simulação de controle de conta

Com um nome de usuário/e-mail + senha (ou hash crackeado off-line) + seed TOTP roubado, um invasor pode gerar códigos válidos de 6 dígitos localmente. Isso significa login completo sem nunca tocar no telefone da vítima.

Se a bolsa oferecer suporte à redefinição de senha por e-mail e à autenticação de dois fatores, e ambos estiverem comprometidos, o invasor poderá bloquear totalmente o usuário. Esse cenário - desvio da MFA usando TOTP roubado ou dados de fator de redefinição - é exatamente o motivo pelo qual os guias de resposta a violações de criptomoedas dizem aos usuários afetados para alternar imediatamente as credenciais, registrar novamente a MFA e monitorar os saques.CCN.com)

Etapa 4: KYC e abuso de identidade

Como os links de imagens do KYC e as varreduras de ID foram supostamente divulgados de forma clara (ou por trás de URLs adivinháveis/alongados), os invasores podem usá-los:

• para abrir novas contas de câmbio em outro lugar como outra pessoa;
• para engenharia social de suporte ao cliente em outros serviços ("Vou lhe enviar meu passaporte agora, por favor, desbloqueie");
• para phishing de usuários de alto valor com detalhes altamente pessoais ("Hi , per AML we froze your withdrawal...").

Já estamos vendo plataformas de criptografia alertarem publicamente que os artefatos KYC vazados se tornam combustível para phishing e fraude personalizados.Análise diária de segurança)

Etapa 5: Direcionamento na cadeia

Os endereços das carteiras e os registros de transações informam quem realmente movimenta grandes volumes. Essa lista é ouro para:

• spear-phishing (golpes de "verificação de segurança"),
• ameaças de extorsão,
• ataques de dusting e golpes de sequestro de aprovação (assine isto, perca fundos).

Os invasores passaram do "roubo de senhas de câmbio" para o "uso como arma de metadados financeiros vazados", porque isso é mais fácil de escalar e faz melhor engenharia social.Análise diária de segurança)

Lista de verificação de defesa e correção (técnica)

Isso é o que a NCX (ou qualquer bolsa de criptomoedas, carteira de fintech ou plataforma com alto índice de KYC) deve fazer imediatamente após descobrir um vazamento aberto do MongoDB.

Linha de base da segurança do banco de dados

• Elimine a exposição pública agoraRemover a instância do roteamento público ou bloqueá-la atrás de regras de firewall/acesso somente à VPC.
• Exigir autenticaçãoPermita a autenticação do MongoDB e o acesso baseado em funções; nunca permita leituras anônimas da Internet.
• TLS em todos os lugaresForçar o transporte criptografado, não o texto simples.
• Princípio do menor privilégioMicrosserviços voltados para o usuário devem ver apenas as coleções absolutamente necessárias.
• Registro e alertaRegistros de auditoria contínua sobre tentativas de acesso e consultas anômalas. Os órgãos reguladores do NIST e da UE esperam registros que mostrem quem acessou o quê, quando, durante e após uma violação.Comissão Europeia)

Governança de segredos e chaves

• Girar chaves de API encontrados na lixeira, presume-se que estejam comprometidos.
• Invalidar "URLs privados" de longa duração para imagens KYC; mova esses ativos para URLs assinados de curta duração com ACL rigorosa (por exemplo, URLs S3 pré-assinados com expiração em escala de minutos, limites de IP e auditoria).
• Proteger APIs de administração internas que as chaves vazadas poderiam atingir: por exemplo, exigir TLS mútuo, listas de permissões de IP, postura do dispositivo.

Redefinição de 2FA / MFA em escala

• Tratar todas as sementes TOTP expostas como queimadas. Forçar o novo registro das contas afetadas.
• Exigir uma nova configuração de 2FA com novas sementes que nunca são armazenadas em texto simples.
• Para contas de alto risco (por exemplo, grandes saldos), adicione temporariamente a verificação gradual para saques e alterações de senha. As equipes de segurança e até mesmo os órgãos reguladores incentivam o "atrito adaptativo" pós-violação em operações de alto valor.CCN.com)

Tratamento de dados KYC

• Mova os documentos KYC para o armazenamento criptografado com controle de acesso rigoroso e tokens de recuperação de curta duração, e não links públicos permanentes.
• Adicione o registro de acesso na camada de objeto (quem visualizou o passaporte X no momento Y).
• Minimize a retenção - o GDPR exige a minimização dos dados e a limitação da finalidade. Se você não precisar de uma digitalização de passaporte em resolução total para sempre, não a guarde para sempre.GDPR)

Disciplina forense + resposta a incidentes

• Faça um instantâneo do banco de dados exposto para obter evidências.
• Capture os registros de acesso antes e depois da remoção para reconstrução da linha do tempo.
• Iniciar o fluxo de trabalho de notificação de violação:
  • notificar a autoridade de proteção de dados em até 72 horas após o conhecimento, a menos que você possa provar que o risco é baixo;
  • notificar os usuários afetados "sem demora injustificada" se houver alto risco para eles (roubo de identidade, aquisição de conta claramente se qualifica).GDPR)
• Documentar toda a cadeia de custódia. Tanto o GDPR quanto a maioria das seguradoras cibernéticas esperam que você preserve as evidências e as etapas de correção.Perkins Coie)

Abaixo está um cronograma simplificado de correção que você espera executar nas primeiras 48 horas após a descoberta:

Órgãos reguladores, como as DPAs da UE e o ICO do Reino Unido, explicitam que a comunicação de violações às autoridades geralmente deve ocorrer dentro de 72 horas após o conhecimento e que você também deve estar pronto para notificar as pessoas afetadas se houver "alto risco" para elas.GDPR)

Mapeamento de conformidade: GDPR, SOC 2 / SOC 3 e expectativas específicas de criptografia

GDPR / proteção de dados no estilo da UE

De acordo com o Artigo 33 e o Artigo 34 do GDPR, se você sofrer uma violação de dados pessoais que coloque em risco os direitos e as liberdades das pessoas, você deverá:

1. notificar a autoridade supervisora em até 72 horas após tomar conhecimento, e
2. informar os usuários afetados "sem atrasos indevidos", descrevendo o que foi exposto e o que está sendo feito a respeito.GDPR)

Para criptografia, o vazamento de KYC + documentos de identidade + metadados de login + sementes de 2FA é absolutamente de "alto risco" para os indivíduos. Ele permite fraude de identidade, perda financeira e engenharia social - os órgãos reguladores não aceitarão silêncio.

Controles no estilo SOC 2 / SOC 3

Na linguagem SOC 2 / SOC 3 (segurança, disponibilidade, confidencialidade), um banco de dados de produção aberto e não autenticado é uma violação direta das expectativas de controle de acesso, segurança de rede e gerenciamento de mudanças. Não é possível ser aprovado em uma auditoria SOC madura se "os dados de identificação pessoal e segredos críticos do cliente estiverem em um IP público sem autenticação".

Notificação de violação e confiança em criptografia

As bolsas de criptomoedas ficam em uma zona estranha: algumas não são bancos totalmente licenciados, mas ainda lidam com dinheiro de clientes, passaportes e dados de AML/KYC. Isso significa que:

• Você é julgado como um custodiante de fintech (proteger os saldos dos clientes, evitar fraudes) e como um controlador de dados (proteger dados pessoais, notificar violações).Análise diária de segurança)
• Se você não notificar, não corre apenas o risco de sofrer multas. Você corre o risco de sofrer danos permanentes à sua marca dentro das comunidades de criptomoedas, que já estão paranoicas depois de anos de hacks e roubos de bolsas.CCN.com)

Como detectar falhas de "classe NCX" antes que a Internet o faça (Penligent View)

Sejamos francos: "MongoDB público sem autenticação expondo mais de 5 milhões de registros" é o tipo de coisa que um loop de teste ofensivo decente deve detectar muito antes dos jornalistas.Análise diária de segurança)

Penligente (https://penligent.ai/) aborda isso como testes adversários contínuos e automatizados, basicamente uma equipe vermelha sempre ativa. Veja como isso é mapeado:

Mapeamento de ativos e monitoramento de exposição

Os agentes da Penligent mapeiam continuamente a superfície de ataque externa (intervalos de IPs na nuvem, subdomínios, serviços vazados) e sinalizam armazenamentos de dados voltados para a Internet, como MongoDB não autenticado, Redis, Elasticsearch, buckets de armazenamento de objetos etc. Essa é exatamente a classe de configuração incorreta que levou à exposição do NCX.Análise diária de segurança)

Simulação de descoberta de dados confidenciais/chaves

Dentro do escopo autorizado, a Penligent tenta identificar as "joias da coroa" de alto valor em serviços expostos:

• Sementes 2FA/TOTP
• Chaves de API e tokens de serviço
• Links ou grupos de documentos KYC
• Metadados da carteira/retirada

A plataforma, então, constrói um caminho de exploração ("com esta semente, podemos gerar códigos MFA", "com esta chave, podemos acessar a API de administração interna"), que é o que os atacantes reais fariam, mas o fazem em uma área restrita controlada em vez de realmente sequestrar contas. Isso cria uma narrativa de risco com base em evidências que as equipes de segurança podem levar à liderança.

MFA e teste do caminho de retirada

A Penligent pode simular o controle condicional de contas: "Se um invasor roubasse essa semente, ele poderia fazer login? Ele poderia fazer saques sem revisão manual? Ele poderia redefinir o e-mail?" Isso lhe dá uma lista ordenada de correções em vez de uma espiral de pânico.

Relatórios de conformidade

Por fim, a Penligent mapeia as descobertas para as obrigações de violação de 72 horas do GDPR, falhas de controle SOC 2 / SOC 3 e risco de custódia de criptografia. Isso é importante porque você não precisa apenas corrigir o bug - você precisa provar que tinha um processo, que tomou medidas e que pode informar os reguladores.GDPR)

Na prática, essa é a diferença entre "não tínhamos ideia de que nosso banco de dados era público há meses" e "temos uma descoberta contínua, detectamos o problema, o contivemos, aqui está o registro".

Perguntas frequentes (para segurança, GRC e engenharia)

Q1. Qual é a configuração incorreta mais comum do MongoDB que leva a violações como o NCX?

MongoDB publicamente roteável, sem autenticação e sem ACL de rede. Muitas vezes, as instâncias de desenvolvimento/teste são promovidas a "produção temporária" e nunca são bloqueadas. A CISA/NIST tem alertado há anos que bancos de dados expostos sem autenticação são uma causa recorrente de vazamentos em grande escala.Comissão Europeia)

Q2. Se uma semente 2FA/TOTP vazar, um invasor poderá fazer login como eu?

Sim, se o invasor também tiver seu nome de usuário/e-mail e sua senha ou um hash quebrado. Com a semente, ele pode gerar códigos válidos de 6 dígitos infinitamente. É por isso que a orientação pós-violação sempre diz: redefina a MFA, não apenas a senha.Análise diária de segurança)

Q3. Como as imagens KYC e as digitalizações de identidade devem ser armazenadas?

Eles devem ser criptografados, controlados por acesso e recuperáveis somente por meio de URLs assinados de curta duração vinculados a uma sessão autorizada, e não por links estáticos que duram para sempre. Todo acesso deve ser registrado. O GDPR também espera a "minimização de dados": não acumule mais dados pessoais do que o necessário.GDPR)

Q4. Com que rapidez temos que notificar legalmente os reguladores e usuários?

De acordo com os regimes no estilo do GDPR, você geralmente deve notificar a autoridade relevante dentro de 72 horas após tomar conhecimento de uma violação que coloque em risco os indivíduos, e deve informar os usuários afetados "sem atraso indevido" se o risco para eles for alto.GDPR)

Linha de fundo

"MongoDB mal configurado" parece um erro de principiante. Em criptografia, é existencial.
Quando você vaza mais de 5 milhões de registros de usuários com IDs KYC, senhas com hash, registros de IP, carteiras e até mesmo sementes TOTP, você não está apenas vazando e-mails - você está vazando identidade, liquidez e confiança.Análise diária de segurança)

Do ponto de vista da equipe vermelha, esse é um caminho de aquisição quase automático.
Do ponto de vista da conformidade, trata-se de um relógio regulatório que não pode ser parado.GDPR)

É por isso que os testes ofensivos contínuos, automatizados e orientados por evidências (descoberta de ativos → simulação de exploração → mapeamento de conformidade) estão rapidamente se tornando obrigatórios para qualquer plataforma de criptografia que armazene KYC e mantenha fundos de usuários. E se você for um usuário de uma bolsa que sofreu uma violação como essa? Mude as senhas, altere o 2FA, presuma que o phishing direcionado está chegando e considere seriamente a possibilidade de sair.CCN.com)