Na semana passada, os desenvolvedores do CMS Drupal fecharam (as
notícias , mais detalhes
em seu site ) duas vulnerabilidades críticas
ao mesmo tempo. Ambos os problemas afetam as versões 7.x e 8.x do Drupal. A vulnerabilidade mais grave foi descoberta no sistema de envio de email interno (DefaultMailSystem :: mail ()). Você pode usá-lo de tal maneira que, ao processar uma mensagem, seja possível executar código arbitrário. A razão para isso, como sempre, é a falta de verificação adequada de várias variáveis.
A segunda vulnerabilidade foi descoberta no módulo Links Contextuais - permite modificar elementos de páginas da web sem ir ao painel de controle. A falta de verificação dos parâmetros passados durante a execução de uma solicitação também pode levar à execução do código. É verdade que, diferentemente da primeira vulnerabilidade, isso é explorado apenas se o invasor já tiver o direito de editar o site.
Essas notícias geralmente não caem no resumo: bem, encontradas, bem fechadas, bem feitas! Mas pelo menos uma vez por ano, vale a pena examinar os sistemas de gerenciamento de conteúdo mais populares e entender no futuro como está a segurança lá. Existe uma fragmentação das versões do CMS, semelhante, por exemplo, à fragmentação da plataforma Android? É tudo tão ruim com a segurança, como, por exemplo, na indústria daqueles dispositivos IoT que não são dispositivos IoT, mas roteadores e câmeras? Vamos ver
Primeiro você precisa entender para onde procurar. Informações suficientemente detalhadas sobre o uso de um CMS específico fornecem
Pesquisas de tecnologia da Web . Os autores do recurso examinam regularmente os 10 milhões de sites mais visitados na Internet (de acordo com a classificação do serviço Alexa) e analisam os sistemas de gerenciamento de conteúdo usados. Os resultados gerais do estudo podem ser vistos
nesta página , e aqui está um gráfico:
Bem, em primeiro lugar, não foi possível obter informações sobre o CMS para 46,1% dos sites, mais precisamente, não há nenhum sistema que esse serviço possa identificar com segurança. Entre os sites em que o CMS foi determinado, o líder indiscutível é o Wordpress, uma espécie de mercado do Android CMS. O segundo e o terceiro lugares com um atraso significativo são ocupados pelo Joomla e pelo Drupal, e no Top10 existem principalmente serviços que oferecem a criação de um site pronto em sua própria plataforma, para quem precisa de mais fácil e rápido. Juntos, Joomla, Drupal e Wordpress estão instalados em 68,8% dos sites com CMS conhecido, ou 37,2% de todos os sites dos 10 milhões estudados.
A fragmentação já é evidente no nível de escolha do CMS: o Wordpress é o líder claro, mas é instalado apenas em um terço dos recursos online, e metade dos sites em geral trabalha por algum motivo. Talvez um administrador sombrio ainda baixe HTML estático via FTP da velha escola. É difícil tirar conclusões dessa variedade: por um lado, a fragmentação complica a vida do invasor; por outro, ninguém sabe realmente como estão as coisas com a segurança de cerca de metade da Internet. Na criptografia, os algoritmos de criptografia auto-escritos foram equiparados a rake afiado. O gerenciamento da web deve ser diferente?
Vejamos a distribuição de versões para os três CMS mais populares. Aqui está a distribuição do Wordpress. A w3techs atualiza seus relatórios diariamente para que as informações sejam as mais recentes.
De alguma forma chata mesmo. Vamos dar uma olhada nos detalhes da versão atual 4.x:
Pouco mais de 70% dos sites Wordpress usam (na data da publicação) a versão mais atualizada (excluindo atualizações regulares da versão principal). Essa, é claro, é uma distribuição mais agradável que o Android, onde a versão atual 8.x é
usada por 19.2% dos dispositivos, mas não tanto quanto gostaríamos.
Há algo a temer? Vamos dar uma olhada no
histórico das versões do Wordpress. A versão 4.9 foi lançada em 15 de novembro de 2017, ou seja, por quase um ano o Wordpress 4.8 e as versões anteriores são obsoletas. Desde a versão 4.9, pelo menos quatro atualizações do CMS foram destinadas a corrigir vulnerabilidades. A gravidade do risco de cada um deles é um assunto para um estudo mais detalhado, embora não tenha havido erros absolutamente críticos no ano passado. No entanto, a
versão 4.9.7 de julho fecha a vulnerabilidade, sob certas condições, permitindo excluir arquivos fora da pasta Uploads.
Vamos ver como está o herói da semana passada - o CMS Drupal.
Essas coisas. A versão mais recente do Drupal 8.x é usada por 11.8% dos sites que geralmente usam o Drupal. O mais popular é o release 7.x. anterior (com justiça, observamos - suportado). O W3techs não fornece detalhes sobre releases específicos dentro do ramo principal, portanto, suponha que todos já tenham sido atualizados (isso, é claro, é uma suposição ousada). De qualquer forma, quase 10% dos sites do Drupal usam versões não suportadas 4.x - 6.x.
A situação para o CMS Joomla é a seguinte:
A versão atual do Joomla 3.8.13 foi lançada recentemente - em 9 de outubro. Você pode ver quantos sites foram atualizados para a versão mais recente em tão pouco tempo.
14,1% de todos os usuários da agência 3.8. Ou 5,8% de todos os usuários do Joomla são aqueles que conseguiram atualizar o site para a versão mais recente em 13 dias. Quais são as consequências se você não atualizar o CMS no prazo? Voltarei aos exemplos do Wordpress, pois esse é o sistema de gerenciamento de conteúdo da web mais popular e mais invadido. Então (de repente), as mensagens sobre o seqüestro prático de sites por atividades maliciosas geralmente mencionam não o código principal do Wordpress, mas seus plugins.
Por exemplo, as
notícias do ano passado sobre plugins realmente atacados, incluindo, por exemplo, o plug-in Flickr Gallery. Em dezembro de 2017, o Wordpress
bloqueou mais três plugins - todos eles foram vendidos pelos criadores, e os novos proprietários implementaram backdoors neles. Aqui está outra
análise do uso de plug-ins que há muito tempo foram abandonados pelos desenvolvedores, têm vulnerabilidades críticas e ainda são usados em centenas de sites.
E não se trata apenas de plugins. Repetidamente, uma senha bruteforce é mencionada como um método de trabalho para atacar sites do Wordpress (por exemplo,
aqui e
aqui ). E esse problema também está além das capacidades dos desenvolvedores do Wordpress. Para complicar a força bruta e não usar as senhas mais simples, é tarefa do administrador e dos usuários dos sites, não dos desenvolvedores.
O que acontece quando um site é invadido com sucesso? Acima, refiro-me às notícias sobre a instalação de mineradores, embora na maioria das vezes os scripts maliciosos clássicos apareçam nos sites. Um caso significativo ocorreu neste verão: em julho, a plataforma de negociação CoinDash foi
invadida , além disso, durante a captação de recursos como parte da OIC. Como exatamente o site foi invadido não é relatado, não pode ser necessariamente uma vulnerabilidade no Wordpress. Mas o resultado é óbvio: na primeira fase de coleta de fundos de participantes privilegiados no site, eles simplesmente mudaram o número da carteira para transferir fundos, como resultado dos quais 7,7 milhões de dólares em equivalente em criptomoeda foram para os atacantes. Há uma
discussão interessante no Reddit sobre isso: não será mais confiável criar uma página estática em casos críticos? Ah, não tenho certeza qual é mais confiável.
Com base nos resultados deste mini-estudo, surge uma pergunta clara: é realmente necessário atualizar o código CMS, se nem sempre existem vulnerabilidades críticas disponíveis, os sites são frequentemente invadidos por plug-ins ou mesmo por força bruta de senha? Como no caso dos
roteadores , um conjunto de medidas traz benefícios reais: atualizar o CMS, revisar a lista de plug-ins instalados e atualizar regularmente os realmente necessários, alterando a URL do administrador, senhas fortes, autenticação multifatorial e apenas auditoria do usuário. A segurança do site (e qualquer outra coisa) é um processo, não um resultado.
Adicione à lista de tarefas, uma verificação regular da versão do CMS não é tão difícil. Se o seu site for gerenciado por uma organização de terceiros, não será supérfluo discutir separadamente o problema da instalação regular de atualizações. Se você já configurou um site uma vez e, desde então, "simplesmente funciona" sem nenhum suporte - você tem problemas. Como vimos hoje, nem todo mundo usa uma medida tão simples para aumentar a segurança de um site como atualizar um código.
Isenção de responsabilidade: as opiniões expressas neste resumo nem sempre coincidem com a posição oficial da Kaspersky Lab. Caros editores, geralmente recomendam tratar qualquer opinião com ceticismo saudável.