O ataque ao MongoDB e a importância de configurações seguras por padrão

Se você tem uma instalação do MongoDB, agora é hora de verificar se ela está segura. Desde pouco antes do Natal, mais de 28 mil instalações públicas do MongoDB foram invadidas. Os atacantes estão mantendo os dados roubados como reféns e exigindo que as empresas paguem em bitcoins para recuperá-los. Pelo que parece, pelo menos 20 empresas já cederam e pagaram o resgate. Neste post, explicamos como foi o ataque, como se proteger e o que podemos aprender com ele.

Entenda o ataque

O ataque em si é alarmantemente simples. Nas versões >= 2.6.0, o MongoDB inclui um arquivo de configuração padrão que vincula o MongoDB a 127.0.0.1 por padrão. Como resultado, o banco de dados só aceita conexões locais.

Antes da versão 2.6.0, não era assim. Por padrão, o MongoDB ficava aberto a conexões remotas. A autenticação também não era obrigatória por padrão, o que significa que instalações do MongoDB antes da versão 2.6.0 aceitavam conexões remotas sem autenticação assim que eram instaladas.

Os usuários ainda podiam restringir o acesso a conexões locais se dedicassem tempo à configuração da instalação, mas isso exigia adicionar manualmente uma linha ao arquivo mongodb.conf. Como essa não era a configuração padrão, muitas instalações existentes nunca incluíram essa etapa essencial.

Para piorar, é fácil identificar possíveis alvos que usam MongoDB. A porta padrão do MongoDB é 27017. Com um mecanismo de busca como o ZoomEye, você pode pesquisar instalações do MongoDB, verificar por quais portas elas estão acessíveis e encontrar cerca de 100 mil possíveis alvos vulneráveis.

A vulnerabilidade em si não é nenhuma novidade. O problema foi apontado pela primeira vez em 2012 e divulgado por volta de 2015. No início de 2015, John Matherly também chamou atenção ao relatar que havia encontrado cerca de 30 mil instalações inseguras do MongoDB. Em outras palavras, todos poderiam estar cientes disso há algum tempo.

O problema das configurações inseguras por padrão

A falta de configurações seguras por padrão não é um problema pequeno. Estudo após estudo após estudo mostra que a maioria das pessoas mantém as configurações padrão de um sistema. As configurações padrão fazem diferença.

Algumas pessoas podem argumentar que certas configurações inseguras por padrão são uma tentativa de equilibrar usabilidade e segurança e se baseiam em suposições razoáveis. Por exemplo, se for seguro presumir que, na maioria dos casos, um banco de dados será instalado atrás de um firewall, talvez pareça razoável, como configuração padrão, não limitar o banco de dados a conexões locais.

Mas suposições como essa são perigosas, porque, quando e não se alguém fizer algo que invalide essa suposição, o sistema ficará vulnerável a ataques — e a pessoa talvez nem perceba. Os possíveis riscos de segurança dessas configurações padrão não são exatamente conhecidos por todos. A menos que a empresa conte com especialistas em segurança para revisar cada decisão (o que é uma boa ideia, mas não é garantido), essas configurações inseguras podem — e muitas vezes acabam — passando despercebidas.

Como acompanhar configurações inseguras por padrão

O problema das configurações inseguras por padrão é ainda mais sério.

Digamos que você faça parte de uma organização responsável e use uma ferramenta como o Snyk para analisar suas ferramentas e dependências em busca de vulnerabilidades. Essas ferramentas não vão apontar esse problema, porque configurações inseguras por padrão geralmente não são consideradas vulnerabilidades. Isso porque, nesse caso, o problema não é um bug nem uma vulnerabilidade no código em si — é uma questão de configuração.

Faz sentido até certo ponto, mas isso levanta uma questão: deveria existir um identificador oficial e um banco de dados de configurações inseguras por padrão?

Por um lado, um serviço que notificasse sobre configurações inseguras por padrão certamente geraria algum ruído. Há muitas configurações inseguras por padrão, e algumas organizações já podem ter corrigido esses problemas. Elas precisariam verificar se o problema ainda se aplica a elas, o que nem sempre é simples. Se não se aplicar, poderiam ignorar o alerta com segurança e seguir em frente.

Mas apontar configurações inseguras por padrão poderia ser muito valioso para quem ainda não identificou esses riscos. Para essas pessoas, isso poderia revelar riscos de segurança que, de outra forma, continuariam despercebidos e sem solução — possivelmente por anos, como aconteceu com o problema do MongoDB.

Sinalizar configurações inseguras por padrão conhecidas em um banco de dados de código aberto (da mesma forma que sinalizamos vulnerabilidades conhecidas) não teria impedido esse ataque, mas poderia ter evitado que pelo menos alguns bancos de dados fossem afetados.

E agora, o que fazer?

Antes de mais nada, proteja sua instalação do MongoDB. Vamos esperar.

Agora que você voltou, este ataque mostra a enorme importância de configurações seguras por padrão. Segurança é importante demais para ser deixada ao acaso. Assim como o setor vem adotando a ideia de que os sites devem usar HTTPS por padrão, quem desenvolve pacotes deve fazer o possível para garantir que eles sejam seguros por padrão. Uma configuração padrão insegura pode causar tanto dano quanto uma vulnerabilidade conhecida. É compreensível que quem desenvolve essas ferramentas queira que a instalação padrão seja simples e sem atritos. Mas, se essa configuração também for insegura, acabamos em situações como a que tantas pessoas enfrentam agora com o MongoDB.

Outra questão levantada por esses ataques é se chegou a hora de começar a registrar configurações inseguras por padrão em um banco de dados de código aberto. Na Snyk, discutimos com frequência se devemos ou não classificar essas falhas como vulnerabilidades, e provavelmente continuaremos essa conversa por muito tempo. Se você tem uma opinião forte sobre o assunto, conte para a gente — por e-mail ou no Twitter. Enquanto isso, se quiser descobrir se há surpresas de segurança nas suas dependências, analise seus repositórios rapidamente com o Snyk.