Recentemente produzimos uma publicação a respeito do uso de exploração da vulnerabilidade CVE-2017-0199 utilizada pelo cibercrime brasileiro. A mensagem principal do post foi alertar acerca da importância das atualizações de segurança (i.e.: patch), mesmo que o WannaCryptor tenha chamado à atenção de todos. Considerando que devemos continuar atentos às vulnerabilidades dos nossos sistemas (independentemente se estão evidentes na mídia) e fazer da aplicação de patches uma atividade rotineira.
Motivado pelo post anterior, resolvi dedicar um tempo para averiguar as vulnerabilidades que mais vêm sendo preponderantes nas detecções da ESET vindas do Brasil.
Principais vulnerabilidades no Brasil em 2017 (até então)
Analisar dados de detecção pode ser uma tarefa aparentemente simples, porém não o é. Deve-se levar em conta que, por vezes, servidores de páginas brasileiras protegidos pela ESET podem estar localizados fisicamente no exterior, ou mesmo no caso de usuários que optam por não compartilhar dados estatísticos com a ESET.
Mesmo assim, as estatísticas atribuídas a um ou outro país são capazes de dizer bastante sobre o que está se passando no cibercrime local. Ironicamente (ou não), a vulnerabilidade líder absoluta de detecção no Brasil até então em 2017 corresponde ao CVE-2010-2568, uma vulnerabilidade que já completou sete anos.
Em segundo lugar, encontra-se o CVE-2017-0147, que em março deste ano ganhou grande notoriedade ao ser utilizada como vetor de propagação do WannaCryptor. Nas próximas três posições subsequentes há uma vulnerabilidade de 2014 (CVE-2014-6332) em quinto lugar, outra de 2016 (CVE-2016-0189) em terceiro e, a vulnerabilidade tema deste post, CVE-2017-5638 do Apache Struts, em quarto lugar.
Não por acaso, todas as vulnerabilidades presentes no TOP 5 de detecção do Brasil possuem exploits disponíveis publicamente.
Por que o CVE-2017-5638 é relevante?
Apache Struts é um framework MVC bastante popular para aplicações web escritas em Java. Apenas para citar uma das consequências “catastróficas” desta vulnerabilidade, tanto vCenter Server Applicance quanto vCenter Server em servidores Windows foram afetados – o que encontra-se com frequência em empresas de médio e grande porte do país.
O CVE-2017-5638 foi publicado no final de janeiro para designar uma falha (i.e.: bug) no processamento do ‘Content-Type’ no header da requisição pelo componente Jakarta Multipart Parser nas versões menores de 2.3.32 ou 2.5.10.1 do Apache Stuts 2. A exploração desta falha permite a execução de comandos remotos no servidor, o que possibilita ao atacante obter total controle sobre o servidor vulnerável.
Em março deste ano, o governo do Canadá decidiu indisponibilizar seu sistema de arrecadação de impostos depois de notarem que seus servidores haviam sido comprometidos através dessa vulnerabilidade. Apenas este caso já seria capaz de ilustrar a relevância do CVE-2017-5638.
Apesar disso, as detecções de ataques explorando o CVE-2017-5638 no Brasil só começaram a ter maior relevância em meados de junho e, atualmente, conta com um nível de detecção bastante acima da média anterior. Em praticamente dois meses, os ataques à vulnerabilidade em questão do Apache Struts chegaram ao patamar de quarto exploit mais detectado/bloqueado no Brasil durante todo o ano.
Uma das possíveis explicações pode ser atribuída ao fato de tutoriais de uso de exploits para o CVE-2017-5638 terem chegado tardiamente a fóruns hacker populares. Isso, porém, não quer dizer que a vulnerabilidade não vinha sendo explorada por grupos mais sofisticados de hackers/crackers (até porque já há módulo para metasploit desde março), no entanto, o volume de ataques era muito menor do que o atual.
Tutorial de uso de exploit para exploração do CVE-2017-5638 em um fórum hacker brasileiro
Portanto, se sua aplicação web está utilizando Apache Struts 2 nas versões vulneráveis, é importante aplicar as correções o quanto antes.
Como corrigir a vulnerabilidade do Apache Struts 2?
Se você utiliza o Apache Struts 2 em uma versão vulnerável, primeiramente é indicado fazer o update para as versões 2.3.32 ou 2.5.10.1.
Há algumas soluções paliativas (“workarounds”) também possíveis, como implementer um servelet para filtrar o Content-Type das requisições e descartar aquelas que sejam suspeitas, ou, no caso do Struts nas versões de 2.5.8 a 2.5.10, é possível remover o File Upload Interceptor e redefinir a pilha de interceptors da aplicação [ver detalhes].
Outra opção, é a aplicação de patch virtual, caso não seja possível realizar nenhuma medida imediata diretamente na aplicação web. A aplicação do patch virtual pode ser realizada por um firewall de aplicação (WAF) ou IPS inline, até mesmo, dependendo da criticidade, contratar soluções de “Security-as-a-Service” diretamente em nuvem que filtram as requisições maliciosas antes que elas cheguem ao servidor vulnerável. Finalmente, há a opção de realizar o patch virtual diretamente no servidor, através de soluções locais de proteção (e.g. expolit blocker da ESET).
Aplicação de patch virtual com WAF/IPS inline
No entanto, a atualização desta falha não é tão simples quanto fazer o update para versões não-vulneráveis e rebootar o servidor. Em alguns casos é necessário fazer o rebuild completo da aplicação web ou mesmo excluir códigos antigos (e vulneráveis) do Jakarta que podem estar sendo incluídos no build da aplicação web.
Portanto, mesmo tendo seguido todos os passos para a correção da vulnerabilidade CVE-2017-5638, independentemente da estratégia escolhida, é de extrema importância testar, com simulações controladas de ataque ao servidor, se a correção foi de fato efetiva. Aliás, essa é uma atividade recomendável sempre que qualquer correção for aplicada.
Informação e ações preventivas é o melhor caminho para manter script kiddies longe dos seus servidores. Fique de olho nas notícias do WeLiveSecurity e não esqueça de aplicar os patches no seu servidor!
