Aumentando a segurança dos bancos de dados MySQL e eliminando o tempo de inatividade

O software de código aberto (OSS) transformou rapidamente a forma como os aplicativos modernos são desenvolvidos e seu código-fonte. O acesso a projetos de software de código aberto robustos e de alta qualidade permitiu que os desenvolvedores integrassem rapidamente novos recursos em suas aplicações sem precisar reinventar a roda. Como resultado, estima-se atualmente que entre 80% e 90% do código na maioria das aplicações modernas seja composto por componentes de código aberto. Da mesma forma, muitas das ferramentas que possibilitaram o crescimento do DevOps e do CI/CD, como Jenkins, Kubernetes e Docker, são elas próprias projetos de código aberto.

Em 2019, o número total de CVEs de código aberto publicados (968) mais que dobrou em comparação com qualquer ano anterior. As vulnerabilidades cresceram 130% entre 2018 e 2019 (de 421 CVEs para 968 CVEs) e foram 127% maiores do que em 2017 (435), ano que registrou o segundo maior número de CVEs no estudo. Esse aumento não parece ser um fenômeno passageiro, já que a descoberta de novas CVEs também permanece em níveis historicamente altos nos três primeiros meses de 2020. Esse volume aumenta a complexidade do gerenciamento da superfície de ataque de uma organização, tanto para desenvolvedores quanto para equipes de TI e de segurança. O servidor de automação Jenkins registrou o maior número de CVEs no total, com 646, seguido de perto pelo MySQL, com 624. Da mesma forma, esses projetos empataram no primeiro lugar quanto ao número de vulnerabilidades exploradas, com 15 (vulnerabilidades para as quais existe código de exploração). Este artigo investiga as razões por trás dessas vulnerabilidades de software e mostra como proteger bancos de dados MySQL contra possíveis incidentes de segurança.

Índice:

1. Uma breve visão geral do MySQL e sua importância no mercado de bancos de dados relacionais

2. Vulnerabilidades no MySQL 
3. Riscos de servidores de banco de dados sem atualizações

4. Softwares de banco de dados com vulnerabilidades devem ser corrigidos rapidamente

5. Conclusão

 

Uma breve visão geral do MySQL e sua importância no mercado de bancos de dados relacionais

Existem vários bancos de dados no mercado, mas o MySQL é um dos mais utilizados tanto em operações internas de back-end quanto em aplicativos voltados para o público, como sites e portais de clientes. Embora seja um banco de dados de código aberto, o MySQL foi adquirido pela Sun Microsystems, que posteriormente foi comprada pela Oracle. Ele foi lançado pela primeira vez na década de 1990, mas rapidamente se tornou uma opção popular em relação ao banco de dados Microsoft SQL Server, que na época era dominante. A sintaxe do MySQL é semelhante à de outras linguagens SQL (por exemplo, Oracle e Microsoft), por isso é uma opção conveniente para desenvolvedores e organizações que precisam de um banco de dados mais acessível.

Atualmente, o MySQL é um dos sistemas de gerenciamento de bancos de dados relacionais (SGBDR) mais utilizados no mercado. Um estudo de 2019 mostrou que o MySQL detinha 38,9% do mercado, seguido pelo MongoDB, com 24,6%, e pelo PostgreSQL, com 17,4%. Acompanhar marcos do ciclo de vida, como o fim da vida útil (EOL) do PostgreSQL 13, ajuda as equipes a evitar a execução de versões de banco de dados sem suporte ao planejarem a aplicação de patches e atualizações. É igualmente importante monitorar as etapas do ciclo de vida de outros sistemas, como as datas de fim de vida útil do MySQL, para garantir que bancos de dados mais antigos não se tornem alvos fáceis. Softwares de banco de dados de código aberto dominam a maioria dos sites, sistemas de back-end e outros servidores de armazenamento de dados operados por empresas.

O software de código aberto que opera a infraestrutura traz muitos benefícios, incluindo uma comunidade que contribui com atualizações, detecção de bugs e desenvolvimento de recursos; pesquisadores de segurança capazes de identificar vulnerabilidades antes que hackers as descubram e explorem; e um repositório compartilhado que pode ser bifurcado e personalizado por outros desenvolvedores. No entanto, esses benefícios vêm acompanhados de uma desvantagem. Se um invasor encontrar um bug, ele poderá explorá-lo em vez de relatá-lo. O resultado pode ser a exploração do software e uma vulnerabilidade de dia zero desconhecida pelo desenvolvedor até que a exploração ou a vulnerabilidade no código seja descoberta. Pode levar potencialmente anos para identificar uma vulnerabilidade que está sendo explorada no momento, o que torna ainda mais crítico para as organizações aplicarem patches no software MySQL assim que uma atualização for lançada. Essas atualizações corrigem vulnerabilidades nos sistemas que poderiam existir há meses e, possivelmente, anos. Se a exploração afetar um banco de dados MySQL de produção que armazena informações confidenciais, é imperativo que a organização aplique as correções no sistema o mais rápido possível.

 

Vulnerabilidades no MySQL 

Devido ao tempo em que o MySQL está disponível ao público e ao fato de sua base de código ser de código aberto, o software de banco de dados possui inúmeras CVEs (Vulnerabilidades e Exposições Comuns) — 1.308 no total. Algumas dessas CVEs estão relacionadas a aplicativos ou softwares, como arquivos de aplicativos PHP que permitem a injeção de SQL para manipular conteúdo da web e executar Cross-Site Scripting (XSS) persistente, mas outras têm como alvo o núcleo do mecanismo do banco de dados. Algumas vulnerabilidades, mesmo as mais recentes de 2020, permitem a escalada de privilégios, acesso à rede para comprometer o cliente MySQL e execução remota de código (RCE).

Um banco de dados comprometido é um evento crítico de segurança, pois permitir que invasores tenham acesso a ele pode gerar diversos outros problemas. Dependendo da vulnerabilidade explorada, os invasores podem extrair dados de um servidor comprometido, obter privilégios administrativos no servidor ou injetar seus próprios dados nas tabelas. Em um ataque XSS persistente, qualquer aplicativo que não codifique os dados do banco de dados pode ficar vulnerável ao roubo de dados ou cookies. Se um invasor conseguir escalar privilégios no servidor, ele poderá manipular dados, extraí-los para um servidor controlado por ele ou realizar movimentos laterais entre os bancos de dados da empresa. A execução remota de código é especialmente perigosa, pois um invasor pode executar seu próprio malware no servidor, que pode ser qualquer coisa, desde keyloggers até ransomware.

 

Riscos de servidores de banco de dados sem atualizações

A título de exemplo, veja CVE-2020-2934. Existem vários outros CVEs relacionados a essa vulnerabilidade, todos afetando conectores, clientes e sessões de rede do MySQL. A exploração bem-sucedida dessa vulnerabilidade poderia permitir que um invasor executasse comandos CRUD (Criar, Ler, Atualizar ou Excluir) no servidor de banco de dados ou lançasse um ataque de negação de serviço (DoS). Um invasor com a capacidade de executar comandos CRUD pode ler seus dados ou fazer alterações neles. Da mesma forma, o fim do suporte ao PostgreSQL 14 pode introduzir vulnerabilidades para organizações que não realizarem a atualização, colocando-as em risco de explorações e ataques devido a versões sem suporte.

Para obter informações sobre as melhores práticas de segurança do PostgreSQL, consulte nosso recurso dedicado ao fortalecimento das configurações de bancos de dados.

Vazamentos de dados em um banco de dados são considerados críticos e têm um impacto duradouro na fidelidade dos clientes, na confiança, na receita e na produtividade. A maioria das organizações não possui uma equipe interna de resposta a incidentes, o que significa que é necessário recorrer a consultores externos que cobram centenas de dólares por hora. Em alguns casos, os administradores de TI optam por desligar sistemas críticos para conter a violação e bloquear o acesso de hackers ao servidor do banco de dados. Essa medida corretiva temporária impede que o invasor roube mais dados, mas também interrompe o funcionamento dos aplicativos que precisam acessar o banco de dados para operar.

Violações graves, nas quais um invasor usa ransomware para criptografar dados ou corromper arquivos, exigem backups e um plano de recuperação de dados. Mesmo em grandes empresas, os planos de recuperação podem falhar e exigir o apoio de consultores externos. Enquanto o banco de dados permanece fora do ar, a organização perde receita devido ao tempo de inatividade, o que pode chegar a milhares de dólares por hora em grandes empresas.

O custo de uma violação de dados em um servidor de banco de dados depende muito do tipo de invasão, da quantidade de dados roubados e da eficiência da resposta ao incidente. A título de exemplo, a instituição financeira canadense Grupo Desjardins gastou US$ 53 milhões após uma violação de dados que expôs informações pessoais de 2,9 milhões de seus membros. A British Airways e a Marriott gastaram US$ 100 milhões cada uma após violarem as normas de conformidade do GDPR (Regulamento Geral de Proteção de Dados), em consequência de violações de dados.

 

Softwares de banco de dados com vulnerabilidades devem ser corrigidos rapidamente

Um ponto em comum a todos os CVEs listados no banco de dados do MITRE para o MySQL é que qualquer aplicativo listado com vulnerabilidades deve receber a correção. Os CVEs podem estar relacionados a softwares de terceiros que permitem injeção de SQL e outras explorações, ou as vulnerabilidades podem ser encontradas no próprio mecanismo de banco de dados do MySQL. Mesmo que você não utilize o aplicativo de terceiros, quaisquer vulnerabilidades no banco de dados MySQL devem ser corrigidas o mais rápido possível.

Como o MySQL é um componente tão essencial da infraestrutura, os administradores e os administradores de banco de dados (DBAs) costumam adiar a aplicação de patches para uma data posterior. Eles também podem esperar várias semanas para aplicar os patches no sistema, a fim de realizar testes completos e evitar tempo de inatividade em um servidor de banco de dados de produção. Cada dia que passa representa uma oportunidade para um invasor explorar o software do servidor MySQL sem os patches aplicados.

Com mais de 1.300 CVEs — e esse número não para de crescer —, pode parecer uma batalha perdida para os administradores e DBAs manterem-se em dia com a aplicação de patches no servidor. Qualquer tempo de inatividade em um servidor de produção significa perda de produtividade e de vendas, e geralmente é difícil programar essas atualizações, já que os administradores não podem interromper os serviços durante o horário comercial de maior movimento.

 

Conclusão

Para manter os servidores atualizados e protegidos contra as vulnerabilidades mais recentes, a solução é utilizar a aplicação de patches em tempo real, de modo que o servidor receba atualizações contínuas sem a necessidade de reinicialização. O KernelCare+ lançará em breve um novo recurso que permitirá aos administradores aplicar patches em seus servidores de banco de dados sem a necessidade de reinicialização. Com o KernelCare+, os administradores podem evitar violações de dados onerosas e tempo de inatividade, ao mesmo tempo em que protegem os dados críticos.