Ataques a CMS: Mantenha “SQL injection” no radar durante o próximo normal
Todos os anos, milhões de sites em todo o mundo são vítimas de ataques de malware projetados para obter acesso ao back-end do site sem o conhecimento do administrador, a fim de roubar dados confidenciais ou causar danos, geralmente para ganho financeiro.
Este ano, os ataques cibernéticos aumentaram durante a pandemia, fazendo com que as empresas se perguntassem se as coisas se acalmarão ou não quando a situação do COVID-19 começar a diminuir, ou se este é o próximo normal para um futuro indefinido.
Ataques direcionados a plataformas populares de sistema de gerenciamento de conteúdo (CMS) como WordPress, Joomla, Drupal e noneCMS aumentaram em 2020. Na verdade, de acordo com o 2020 Global Threat Intelligence Report da Dimension Data, essas plataformas CMS sozinhas foram o alvo de aproximadamente 20% de todos os ataques observados globalmente. A vulnerabilidade de injeção de SQL no Joomla foi considerada a mais comumente explorada pelos invasores.
Neste artigo, daremos uma olhada nas vulnerabilidades de segurança no contexto das plataformas CMS e nas implicações dos ataques de injeção de SQL em seu site.
Como as vulnerabilidades do CMS evoluíram ao longo dos anos
As vulnerabilidades do CMS afetam a segurança do seu site, bem como o sistema de gerenciamento de conteúdo que você usa. Alguns dos motivos comuns para vulnerabilidades de CMS incluem explorações de escalonamento de privilégios, ataques de engenharia social e scripts entre sites.
- As explorações de escalonamento de privilégios envolvem o uso de falhas de segurança, bugs conhecidos ou falta de supervisão de configuração em um aplicativo ou sistema operacional para obter acesso total aos recursos.
- Ataques de engenharia social em CMSs incluem uma ampla variedade de atividades maliciosas que são usadas para contornar medidas técnicas implementadas para proteger o processo de gerenciamento de conteúdo.
- Cross-site scripting (XSS) utiliza falhas de segurança em ambientes de execução do lado do cliente, bem como vulnerabilidades no back-end, como a falta de verificação de conteúdo e parâmetros para divulgar dados confidenciais, permitindo que invasores assumam o sistema.
A maioria das falhas de segurança vinculadas às plataformas CMS não se limitam ao gerenciamento de conteúdo da web, mas estão presentes em ambientes de servidor, tecnologias da web e protocolos.
Cross-site scripting
O script entre sites tem como alvo o ambiente do cliente e usa o parâmetro baixo do lado do servidor e a higienização de conteúdo. Como resultado, o invasor pode injetar código malicioso e comandos arbitrários nas páginas que os usuários visualizam.
Essa falha de segurança difere das vulnerabilidades de execução de código, uma vez que o código injetado é executado no cliente-servidor e não no lado do servidor. Isso atrasa o impacto técnico da ameaça. No entanto, quando executado de forma eficaz, pode resultar em sérias violações de dados e privacidade, como a manipulação de bancos de dados e variáveis armazenadas, incluindo a manipulação do conteúdo real servido.
Esse tipo de vulnerabilidade de segurança de aplicativo da web geralmente tem como alvo as plataformas CMS populares, já que dependem fortemente da Internet para sua arquitetura técnica. Como alternativa, essa ameaça pode ser facilmente neutralizada desativando o ambiente de execução do lado do cliente.
CMSs de código aberto, como WordPress e Drupal, que dependem fortemente do ambiente do lado do cliente, são mais propensos a ataques do lado do cliente em comparação com estruturas corporativas tradicionais que exibem vulnerabilidades remotas do lado do servidor. O crescimento de plug-ins CMS de terceiros também contribuiu para que os scripts entre sites se tornassem uma das principais vulnerabilidades de segurança para plataformas CMS.
Execução de código remoto arbitrário
O envio de comandos maliciosos para um aplicativo da web pode resultar na divulgação dos dados privados dos usuários, e o invasor pode obter acesso ao computador do usuário. Esse método de injeção de código na mesma infraestrutura de execução local é relativamente fácil quando comparado à injeção remota, que requer ferramentas e habilidades mais especializadas.
Aqui, o hacker remoto só precisa de uma falha de segurança que oferece uma pequena janela para enviar comandos ao ambiente de execução remota, permitindo que o código malicioso seja executado sem qualquer avaliação.
Como resultado, os invasores podem criar uma entrada remota para atingir o ambiente de destino e, muitas vezes, o administrador não tem conhecimento do sistema que está sendo comprometido.
Na maioria das vezes, os invasores usam falhas de segurança de execução remota de código que estão na superfície da Web ou em portas e protocolos específicos e de uso restrito. Quando um CMS é atacado, a falha de execução remota de código geralmente resulta de uma plataforma conectada, como o ambiente .NET, linguagem de script PHP ou serviço de compartilhamento de arquivos ou banco de dados com vulnerabilidades de execução remota de código.
Em vez de visar a infraestrutura remota, às vezes os agentes de ameaças mudam suas táticas, iniciando ataques de execução remota de código no ambiente do cliente. Por exemplo, um e-mail malicioso pode conter um anexo contendo um arquivo infectado especialmente criado. O arquivo contendo o código malicioso é executado na infraestrutura do cliente. Pode, por exemplo, permitir que o invasor instale programas ou crie novas contas com direitos totais de usuário.
Em ambos os tipos de ataques, o código malicioso pode ser o mesmo. No entanto, o método de entrega é diferente. É por isso que é vital para os administradores de CMS proteger suas plataformas e não permitir que invasores entrem nos sistemas dos usuários finais. Desde 2017, a execução remota de código arbitrário surgiu como uma das principais vulnerabilidades de segurança do CMS. Várias falhas de segurança foram detectadas no CMS do Magento, incluindo execução arbitrária de código.
Injeção SQL e o CMS
Atualmente, a maioria das plataformas CMS tem um back-end de banco de dados SQL subjacente. Esses bancos de dados de back-end implementam autenticação específica do aplicativo em vez de credenciais no nível do usuário. Como resultado, quando um código malicioso é introduzido em uma camada da web na forma de uma injeção de SQL, uma violação na segurança dos dados afeta todo o banco de dados.
Como com outras ameaças de injeção de código, uma injeção de SQL é capaz de enviar código SQL arbitrário direto para a camada de banco de dados. Na maioria dos casos, a falta de sanitização de parâmetros é responsável por esse tipo de vulnerabilidade de segurança, pois permite que o ator da ameaça envie comandos diretos do banco de dados e modifique o banco de dados diretamente.
As injeções de SQL já existem há muito tempo e continuam sendo uma das falhas de segurança mais comuns do CMS. Com o tempo, os usuários descobriram novos pontos de injeção. Executar a sanitização de valor de parâmetro para processamento de valor de entrada é uma maneira comum de interromper ataques de injeção de SQL.
Algumas das plataformas CMS mais populares que são conhecidas por terem vulnerabilidades de injeção de SQL incluem WordPress, Joomla e Drupal. De acordo com o Relatório de Pesquisa de Ameaças de Sites de 2019 da Sucuri , mais de 2 milhões de tentativas de ataque de injeção de SQL foram bloqueadas pelo Firewall da Sucuri, representando 1,55% de todas as tentativas de ataque bloqueadas.
Consequências das injeções de SQL em plataformas CMS
O objetivo de uma plataforma CMS é se conectar a um banco de dados que armazena conteúdo, incluindo tanto informações estruturadas quanto dados relativos a usuários registrados com funções diferentes.
De acordo com a Sonicwall , houve um aumento considerável nos ataques a aplicativos da web executados por injeção de SQL. Os ataques a aplicativos da Web, que são comumente executados por injeção de SQL, diminuíram em relação ao ano passado, mas têm uma tendência perigosa de aumento desde fevereiro, com 2,1 milhões de ataques aumentando continuamente para 4,9 milhões em junho.
Em um ataque de injeção de SQL, o invasor envia a entrada SQL em um campo de entrada para execução ou para obter acesso a um aplicativo da web sem a permissão ou conhecimento do proprietário. Isso permite que o usuário malicioso visualize, insira, modifique ou exclua os dados armazenados nas tabelas de banco de dados do aplicativo da web. A maioria dos invasores usa injeções de SQL para explorar vulnerabilidades de segurança conhecidas em plug-ins e aplicativos como PHP.
Aqui está um exemplo de como funciona uma injeção de SQL. Suponha que um aplicativo da web com entrada de texto peça ao usuário para inserir seu ID de usuário para identificação:
SELECT * FROM Users WHERE UserId = " + txtUserId
A entrada inserida pelo usuário “202 ou 1 = 1” onde 202 é o ID de usuário incorreto. Isso altera o código do servidor da seguinte maneira:
SELECT * FROM Users WHERE UserId = 202 or 1=1
Como a condição 1 = 1 sempre é verdadeira, todas as entradas na tabela Usuários do banco de dados são retornadas por esta instrução. Agora, se seu código foi escrito para selecionar a primeira linha no SQL , isso poderia comprometer os dados armazenados em várias tabelas de banco de dados.
Vamos dar uma olhada em algumas das consequências dos ataques de injeção de SQL em plataformas CMS:
- Não há necessidade de autenticação para um login bem-sucedido: o ator da ameaça não é solicitado a se identificar antes de fazer o login no seu site, dando acesso aberto aos recursos do site.
- Configurando redirecionamentos: envolve o invasor colocando links de redirecionamento mal-intencionados nas páginas do seu site, que direcionam os visitantes do site para sites onde eles são enganados ou o sistema é infectado por malware.
- Spamming: os invasores usam técnicas de spam para monetizar produtos fraudulentos em seu site. Eles podem infectar seus aplicativos, permitindo que eles se comuniquem diretamente com os usuários do seu site.
- Ataques DDoS: os invasores usam ataques DDoS para interromper os serviços do seu site temporariamente ou indefinidamente, resultando em sérios danos financeiros.
Existem várias maneiras de prevenir ataques de injeção. As medidas mais comuns incluem:
- Implementando segurança de aplicativo da web: Um firewall de aplicativo da web (WAF) é uma solução de segurança obrigatória para qualquer site ou aplicativo ativo hoje. Um WAF evita que tráfego e processos maliciosos interajam com sua plataforma CMS.
- Usar validação de entrada: as plataformas CMS mais populares já verificam os dados enviados por meio de campos e formulários. Mas caso você vá fazer customizações que envolvam a adição de campos, certifique-se de ter scripts que filtrem todos os dados enviados pelos usuários.
- Acesso seguro ao seu banco de dados. É melhor criar um usuário SQL exclusivo com uma senha forte para cada uma das instalações do CMS. Evite fornecer acesso de nível raiz, limitando os privilégios do usuário. WordPress, por exemplo, pode trabalhar apenas com os privilégios SELECT, INSERT, UPDATE, CREATE, DELETE, DROP e ALTER.
- Mantenha tudo atualizado. A plataforma CMS e os desenvolvedores de plugins também mantêm suas bases de código para segurança. Muitos de seus lançamentos têm como objetivo resolver bugs e vulnerabilidades. Se sua plataforma CMS o notificar sobre uma atualização, verifique se isso inclui correções de bug e segurança. Atualize de acordo.
Conclusão
Milhões de sites são vítimas de ataques de malware a cada ano e resultam em enormes perdas financeiras. No entanto, os proprietários de sites podem prevenir ou minimizar com sucesso o impacto de tais ataques corrigindo vulnerabilidades de forma proativa (como vulnerabilidades de injeção de SQL) em seus CMS.
Existem várias medidas que você pode tomar para evitar ataques de injeção de SQL, mas elas devem ser implementadas como parte de uma estratégia coesa. Ao implantar as ferramentas de segurança certas, testar continuamente seu site e consertar quaisquer falhas aparentes, você pode ficar à frente dos invasores que tentam explorar vulnerabilidades do CMS.
