hasegawatadamitsu/cve-2014-0094-test-program-for-struts1Programa de teste CVE-2014-0094 para struts1
Resumo sobre o impacto do CVE-2014-0094 no struts1. Salvo indicação em contrário, cada versão foi verificada com java 1.7.0_02, struts 1.3.10, apache-tomcat-6.0.39, FreeBSD 8.2.
Note: Em nenhum caso, o conteúdo do código-fonte, textos, etc. é garantido. Além disso, não me responsabilizo por qualquer evento que ocorra. Especialmente se este conteúdo for usado indevidamente, não tenho qualquer envolvimento. (Embora não haja nada de novo nisso).
Desta vez, apresentei exemplos concretos de soluções com base em vários sites. Exceto por fatos conhecidos, as URLs de referência foram listadas nas fontes, etc. Agradeço pela divulgação das informações.
Tentei não usar jargões técnicos, embora possa haver alguma imprecisão, escrevi em palavras fáceis de entender.
Quanto à vulnerabilidade atual no struts1, não está claro se existem nomes como CVE-2014-0094, S2-020 etc., mas por enquanto vamos chamá-la de CVE-2014-0094.
Desnecessário dizer que o CVE-2014-0094 apresenta um problema muito grande.
http://www.nta.go.jp/sonota/sonota/osirase/service.htm
「e-Taxソフト（WEB版）」、「確定申告書等作成コーナー」、「NISA（日本版ISA）コー\ナー」 サービス停止のお知らせ（重要）平成26年4月25日
De acordo com isso, o serviço web da Agência Tributária Nacional usava struts1 e parou o serviço no mesmo dia em que foi descoberto.
Acredita-se que a paralisação foi feita rapidamente para minimizar os danos.
Quando realizei uma prova de conceito aqui, apenas acessando a URL, confirmei a interrupção do serviço e o vazamento de arquivos arbitrários.
Como é apenas acessar a URL, com um endereço de e-mail anônimo, basta enviar um e-mail com a URL para uma lista de discussão, dificultando a identificação do culpado, e é fácil derrubar o serviço.
É um problema que pode ser atacado tão facilmente.
Isto é o mais importante. Se houver um anúncio de uma entidade terceira de que há pelo menos um impacto, pare primeiro para evitar a propagação dos danos - essa é a maneira correta.
Mesmo que uma investigação posterior revele que não houve impacto, as informações vazadas não podem ser recuperadas. Naturalmente, é necessária uma decisão política. No caso de empresas, são questionadas a ética, a consciência dos problemas do dia a dia, a gestão de riscos, etc.
Este problema decorre do fato de que alguns valores de configuração mantidos pelo sistema podem ser reescritos. É necessário investigar quais valores de configuração podem ser reescritos. Dependendo desses valores, determina-se que tipo de ataque é possível.
Esses valores de configuração variam de acordo com o container Servlet. No tomcat6, a execução de código arbitrário é provavelmente impossível, mas no tomcat8 é possível a execução arbitrária. Além disso, dependendo do ambiente usado, como jetty, WebSphere Application Server, etc., é necessário verificar quais valores de configuração existem.
No caso do tomcat6, diz-se que 23 dessas configurações podem ser alteradas. Se class.classLoader.resources.dirContext.docBase for alterado, a operação normal do sistema se torna impossível e, ao especificar um arquivo no servidor em vez de exibir JSP, qualquer arquivo pode ser obtido (vazado).
No caso do tomcat8, a execução de código arbitrário é possível, porque há mais valores que podem ser configurados em comparação com o tomcat6. Se esse valor de configuração não existir no container Servlet em uso, acredita-se que atualmente o problema seja menor.
A alteração do valor de configuração desta vez pode ser feita não apenas incluindo essa string na URL, mas também como um campo oculto em uma requisição normal, e também é possível incluir esse valor em cookies.
A partir dos logs de acesso, não é possível saber se foi definido como campo oculto.
Há casos em que a reinicialização é feita frequentemente no domingo à noite, mas um pouco antes disso, a reescrita do docBase e a obtenção de arquivos são realizadas, e depois a reinicialização ocorre no sistema, tornando difícil para o administrador notar algo anormal.
Se houver muitas ocorrências de status 404, 500 etc. visando esse período, é provável que algum arquivo tenha vazado.
O sturs1 não tem mais suporte (deixando de lado a questão "o que é suporte de código aberto?"), e nenhum patch de segurança será lançado. É necessário resolver por conta própria.
A origem do problema está no BeanUtil, e é necessário implementar uma lógica para ignorar strings inadequadas que cheguem a ele.
BeanUtil é uma ferramenta que altera os valores de configuração de objetos (é uma expressão bastante imprecisa).
Exemplo de implementação:
com.haselab.struts.filter
web.xml
Explicando de forma simples, no web.xml, um programa que altera o comportamento do BeanUtil é chamado na inicialização do sistema.
SafeResolverListener.java é chamado, e a partir de agora o BeanUtil usará SafeResolver.java.
No SafeResolver.java, se a string a ser analisada for 'classLoader' (ignorando maiúsculas/minúsculas), ele retorna "" (string vazia).
Ou seja, impede que qualquer valor seja definido para classLoader.
Quanto a esse comportamento, consultei https://gist.github.com/nakamura-to/11347570 (É um programa curto, então é exatamente como está.)
Se for necessário alterar a configuração chamada classLoader no lado da aplicação, este método não permitirá essa alteração, portanto não é uma solução viável.
No entanto, geralmente não se deve nomear algo como classLoader, então a princípio não há problema.
Se estiver preocupado, execute grep -r -i classLoader * em todo o código-fonte da aplicação e verifique se não existe. Pode-se documentar que não está presente.
Verifiquei a reescrita do docBase. Após o deploy com mvn, visualize o diretório struts no navegador. A cada pressionamento de botão, a reescrita do docBase e a exibição do arquivo /etc/passwd são realizadas.