Nunca deixe seu banco de dados em nuvem publicamente acessível

Views: 804

Introdução

Na segurança cibernética, muitas vezes ouvimos falar sobre as melhores práticas, uma das mais importantes delas é nunca abrir serviços que deveriam ser para uso interno ao acesso público. Essas são as melhores práticas por uma boa razão – quando você não as segue, você pode ser hackeado!
Pesquisas que realizamos no passado mostraram como os hackers poderiam usar os serviços Docker e Redis que foram deixados expostos a seu próprio benefício.

Investigações sobre a causa raiz das violações de dados muitas vezes apontarão para a mesma negligência onde os serviços são deixados publicamente acessíveis, seja por engano ou intencionalmente para um propósito específico por um tempo limitado.

Quando se trata de bancos de dados, uma das regras mais importantes é nunca expor seu banco de dados ao acesso público. Em ambientes de nuvem, no entanto, é muito fácil cometer esse erro porque seu provedor de nuvem pode permitir que isso aconteça com apenas alguns cliques.
Usando o Shodan, podemos rapidamente obter uma estimativa de bancos de dados abertos publicamente. A Figura 1 mostra estatísticas relacionadas ao MySQL e Postgres. Em “Top Organizations” você pode ver provedores de nuvem como Amazon e Alibaba.

Figura 1: Abra publicamente os bancos de dados MySQL e Postgres da Shodan

Neste blog, vamos demonstrar o que pode acontecer dentro do seu banco de dados quando você deixa a porta aberta.

Honeypots

Uma das maneiras mais eficazes de aprender como os hackers operam é implantar potes de mel.
Tomando essa abordagem, criamos vários Serviços de Banco de Dados Relacional (RDS) na AWS e os deixamos abertos. Para atrair hackers, inserimos dados e informações de pagamento do Identificador de Informações Pessoais (PII).
Na Figura 2, você pode ver que não demorou muito para os hackers descobrirem e fazerem a primeira tentativa de conexão com o banco de dados. Além disso, o tempo para o primeiro ataque também foi muito curto.

Figura 2: Estatísticas do Honeypot

Durante a pesquisa, observamos vários tipos de ataque. Vamos dar uma olhada mais profunda neles.

Tipos de ataque

Visão geral

Quebra de senha usando ataque de dicionário

Uma vez que seu banco de dados é público, a primeira coisa que os hackers farão é tentar se conectar a ele, começando usando vários métodos de quebra de senha. Nós nos referimos a isso como fase um.
Observamos vários ataques, alguns deles realizados a partir de um único IP, enquanto outros de 115 IPs diferentes, muitas vezes da mesma Classe C, com 170 usuários diferentes de DB. No total, durante um período de um mês, observamos 23.000 tentativas de conexão diferentes ao banco de dados. Os usuários de DB mais populares usados nos ataques foram: root, admin, mysql, user, backup, test, phpmyadmin, mysqld, sa e ADMIN.

Na Figura 3 você pode ver um ataque de quebra de senha no MySQL DB realizado por vários IPs.

Figura 3: Ataque de quebra de senha feito por vários IPs

Identificamos dois tipos de comportamentos. Após uma conexão bem sucedida com o banco de dados, o primeiro deles inicia imediatamente a fase dois do ataque – a exploração adicional do banco de dados, como a implantação de malware.
O segundo tipo, depois de se conectar com sucesso ao banco de dados, desconecta-se imediatamente e salva as credenciais para uso posterior. Em uma ocasião, observamos um intervalo de cinco dias entre as fases um e dois.

Sondagem de dados

A sondagem de dados, como mostrado na Figura 4, é um passo que os hackers realizam para inspecionar os dados, a fim de decidir se ele tem algum valor e se deve ou não continuar o ataque.

Figura 4: Ataque de sondagem de dados

Backdoor do usuário DB

Observamos conexões com o banco de dados (DB) onde a única coisa que aconteceu foi a criação de um novo usuário de DB, como mostrado na Figura 5. Nossa suposição educada é que este usuário DB estava sendo usado como um backdoor para acesso posterior.

Figura 5: Ataque backdoor do usuário DB

Aquisição de DB

Neste ataque, os hackers iteram todos os usuários de DB existentes e modificam sua senha, deixando-o fora do seu próprio banco de dados. Na Figura 6 você pode ver um exemplo de onde o hacker conseguiu uma lista de usuários com privilégios específicos e, em seguida, modificou a senha de usuário “administrador”.

Figura 6: Ataque de aquisição de DB

Implantação de malware

Os hackers também podem usar o SQL para baixar e executar arquivos maliciosos na máquina de banco de dados. Para obter informações adicionais, você pode ler: Um mergulho profundo nos ataques de banco de dados [Parte IV]: Entrega e Execução de Executáveis Maliciosos através de comandos SQL (MySQL)

Ransomware

O Ransomware geralmente está associado a um malware que criptografa seus dados e exige que você pague um resgate para poder liberá-los. Vamos mergulhar fundo em uma versão deste ataque na próxima seção.

Mergulho profundo no ataque de ransomware

No contexto do ransomware em bancos de dados, os hackers despejam seus dados, excluem-nos e deixam uma nota de resgate.

Figura 7: Nota do Ransomware

Em nosso projeto honeypot, fomos testemunhas de inúmeros ataques de ransomware em nossos bancos de dados por diferentes grupos de hackers. A Figura 8 mostra um fluxo de ataque de ransomware em um pote de mel MySQL:

Figura 8: Fluxo de ataque de ransomware

As seis fases do ataque:

1. Colete credenciais

usando o ataque do dicionário: O hacker usou um ataque de dicionário para adivinhar usuários e senhas do DB. Na linha 5, o hacker conseguiu conectar o DB com um usuário ‘administrador’. Ele então se desligou e continuou a tentar adivinhar usuários adicionais de DB.

2. Executar o

roteiro de reconhecimento: Depois de cinco dias, o hacker voltou e começou seu ataque. No início, ele executou um roteiro de reconhecimento para descobrir o seguinte:

• Todos os usuários de DB
• Todos os bancos de dados que não são padrão
• Todos os usuários de DB que têm permissões “SELECT” e “INSERT”
• O tamanho dos bancos de dados

3. Use “mysqldump”:

Examinando as consultas (veja abaixo) chegamos à conclusão de que o hacker usou mysqldump para exfiltrar os dados.

Uma vez que ele tinha todos os dados, o hacker deixou cair o banco de dados:

4. Ressira

banco de dados: O hacker criou um novo banco de dados com o mesmo nome que tinha antes e inseriu uma nota de ransomware.

5. Crie um

novo banco de dados: O hacker criou um novo banco de dados chamado “PLEASE_READ_ME_XMG” para chamar a atenção do administrador do banco de dados, usando a mesma nota de ransomware de antes.

6. Crie backdoor

do usuário DB O hacker criou um backdoor criando um novo usuário DB e concedeu-lhe permissões administrativas. Dessa forma, o hacker ainda seria capaz de se conectar ao DB, mesmo que o administrador decidisse alterar a senha para todos os usuários que ele estava ciente.

O resultado final do ataque – nosso banco de dados honeypot foi sequestrado.

Depois de analisar o ataque decidimos entrar em contato com o hacker para obter mais informações sobre sua operação. Usamos uma conta de e-mail falsa e pedimos a ele provas de que ele possuía, de fato, nossos dados. Em troca, ele nos enviou uma captura de tela do lixão.

Figura 9: Fale com o hacker

Suspeitamos que hackers usam ferramentas legítimas para despejar bancos de dados. Agora tínhamos provas de que “mysqldump” estava sendo usado para exfiltrar dados de bancos de dados neste caso.

Isso levanta a questão: os hackers usam ferramentas legítimas para despejar bancos de dados?
Para responder a essa pergunta, tivemos que colocar as mãos nos depósitos de banco de dados de violações de dados anteriores.
Navegamos em fóruns de hackers e baixamos alguns lixões.

Figura 10: Despejo usando o despejo do administrador MySQL

Figura 11: Despejo usando despejo MySQL

Figura 12: Despejo usando despejo mysql do administrador

Como mostrado nas figuras 10 a 12, esses lixões são criados por ferramentas legítimas.

Conclusão

Nosso objetivo era entender como hackers atacam bancos de dados. A suposição era que os hackers usam técnicas/ferramentas sofisticadas para realizar seus ataques, mas aprendemos que nem sempre é assim. Ferramentas legítimas geralmente

são usadas para operações administrativas, como backup de banco de dados, mas também são usadas por hackers para exfiltrar seus dados.
Dessa forma, os hackers podem mascarar suas atividades maliciosas.

Este blog mostra a ponta do iceberg quando se trata do que pode acontecer em seu banco de dados aberto.

Como posso proteger meu banco de dados?

Recomendamos que você siga as melhores

práticas,

por exemplo: Desativar o acesso público Alterar senhas

padrão Implantar políticas de senha (expiração, bloqueio, complexidade, etc.)

Pesquisar consultas ou operações arriscadas, por exemplo:

• Backdoor do usuário BD
  • ‘CRIAR USUÁRIO’
  • ‘insira no mysql.user’
• Aquisição de DB
  • ‘selecione Usuário do usuário onde Select_priv=”Y” e Insert_priv=”Y”‘
  • ‘atualizar senha do conjunto de usuário =’
  • ‘atualizar o conjunto de usuário authentication_string =’
• Implantação de malware
  • ‘tabela criada (dados LONGBLOB)’
  • ‘CONCAT”,’0x4D5A9…’)
  • ‘Into’ e ‘DUMPFILE’
  • ‘CRIAR FUNÇÃO’ e ‘.dll’
• Ransomware
  • ‘PLEASE_READ’
  • ‘INSERÇÃO EM ‘AVISO”

Você também pode procurar logins com falha para encontrar ataques de força bruta.

O produtoCDS(Cloud Data Security, segurança de dados na nuvem) do Imperva pode ajudá-lo a detectar alguns dos ataques, como a criação de novos usuários de DB e ataques de força bruta.
Estamos atualmente no processo de adicionar algoritmos de detecção no produto CDS.

FONTE: IMPERVA