Proponha uma correção, faça uma sugestão
Spring4Shell: Há uma nova falha grave no Java a afetar a Internet e a maioria dos seus serviços
A segurança na Internet é um tema constante e de forma recorrente surgem problemas com o novo Spring4Shell. Colocam em causa os utilizadores e os seus dados, bem como os serviços que são fornecidos em cima destas plataformas.
Esta é mais uma falha do Java e dos seus componentes, com um grau de severidade elevado. Depois do Log4j, este é mais um problema grave e que deve ser resolvido com a máxima brevidade, para garantir a segurança de todos.
Spring4Shell: A nova falha do Java
Uma nova investigação levada a cabo por especialistas de segurança revelou mais uma falha no Java. Esta está presente na estrutura Spring Core Java e tem o nome "Spring4Shell", tendo sido revelada publicamente, CVE-2022-22963, sabendo-se que permite a execução remota de código não autenticado em aplicações.
Segue a mesma linha da conhecida Log4j e tem mesmo grande relevância. Deixa os serviços que usam esta framework vulneráveis e expostos a ataques de vários tipos. O código para a sua exploração está já disponível em certos círculos e sabe-se estar a ser usado.
A Java Springcore RCE 0day exploit has been leaked. It was leaked by a Chinese security researcher who, since sharing and/or leaking it, has deleted their Twitter account.
— vx-underground (@vxunderground) March 30, 2022
We have not verified the exploit.
tl;dr big if true
Download the 0day POC here: https://t.co/SgPCdI00TS
Apps e serviços estão vulneráveis
Apesar de estar ainda a ser avaliada, a nova falha Spring4Shell parece ser extremamente crítica e passível de expor os serviços e apps onde está presente. Se os requisitos forem satisfeitos, é possível colocar ficheiros nos servidores, usados depois para roubar dados.
Uma boa notícia que surgiu, entretanto, veio colocar um pouco de calma neste processo. Uma análise preliminar determinou que é necessária a presença de "Spring Beans", usar "Spring Parameter Binding" e uma "Spring Parameter Binding" deve ser configurada para usar um tipo de parâmetro não básico, como POJOs.
The following non-malicious request can be used to test susceptibility to the @springframework 0day RCE. An HTTP 400 return code indicates vulnerability.
— Randori Attack Team (@RandoriAttack) March 30, 2022
$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0#SpringShell #Spring4Shell #infosec
Atualizações são essenciais por agora
A recomendação por agora é a atualização de todas as apps e serviços que usem a versão 9 ou posterior do Java. Espera-se que surjam correções nos próximos dias e que removam a vulnerabilidade Spring4Shell de forma definitiva.
Pensa-se que poderá ter o mesmo impacto que o Log4j teve, e que ainda não foi resolvido em muitos casos. Devido aos requisitos para explorar esta falha, é muito cedo para dizer quantas apps e serviços podem estar vulneráveis.
Este artigo tem mais de um ano
Loading ...
A vulnerabilidade já se encontra corrigida nos novos patches de Spring 5.2.x e 5.3.x, bem como no Spring-Boot 2.5.x e 2.6.x.
O Java já devia de ter morrido.
Uma vez que a Internet acabou com o Flash, já lá vai o tempo que o Java devia de seguir a mesma tendência.
O HTML5 substitui já e muito bem estas tecnologias do milénio passado que são cavalos mortos.
Agora vêm os defensores do Java agarrados ao passado que não sabem programar em mais nada em 3, 2, 1 …
Spring é uma framework de backend, nada tendo a ver com as Java applets que essas sim já morreram (ou já deveriam ter, mas o nosso estado continua agarrado a elas).
A vulnerabilidade nada tem a ver com o Java, mas sim com a framework Spring.
Quanto ao resto do comentário, é pena que o HTML5 ainda não conseguiu substituir todos os trolls desta vida.
Eu não uso Java, mas o teu comentário é bem claro numa coisa: Misturar Java com HTML é um erro típico de quem não sabe do que está a falar.
HTML5 > Java xDDDD
No outro dia estava aqui a comentar em fóruns sobre temas que não domino e que não tenho qualquer tipo de conhecimento ou formação (mais ou menos o que você está a fazer), e foi me sugerido fazer uma aplicação para treinar e melhor perceber o conceito de Multi-Threading, então fiz em HTML5 (xDDDDD) e a minha vida desde então melhorou imenso. Hoje sou um programador de renome em todo o mundo graças às minhas habilidades de programação em HTML5. Estou a caminhar para o primeiro M1lhão na minha conta.
Alguém que explique ao rapaz a diferença entre o java do artigo e java que ele está a falar, sff.
Gostaria apenas de sugerir uma correcção de linguagem.
Apesar de parecer um pormenor técnico é relevante: a falha é potencialmente muito grave, mas não é “no Java”. Antes é numa framework muito popular que usa a linguagem Java – o Spring – num dos seus componentes.
É similar para o Log4JShell, que foi uma falha numa biblioteca de logging muito popular no mundo Java, mas não no Java em si.
Isto é importante porque o ecossistema Java é muito mais vasto do que o Log4J e o Spring.
Se a vulnerabilidade fosse no Java (a linguagem + o JDK) aí sim, seria de uma potencial gravidade largas vezes maior, uma vez que seria, para todos os efeitos, nos blocos de constroem cada uma destas coisas.
Cumprimentos
Bravo acho que disseste tudo. Muito bom comentário.
De realçar que para quem usa a framework Spring, afecta apenas quando usado o Java JDK 9+, Apache Tomcat (outros webservers podem ser também vulneráveis mas até à data apenas o Tomcat é certo), e aplicações deployed em formato WAR.
E claro, para quem usa já estão disponíveis patches. Quem não pode por algum motivo actualizar, neste link está disponível uma fix temporária:
https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
É verdade. Felizmente precisa de um cenário um pouco mais complexo do que quando foi com o Log4JShell.
Também é um bom aviso ao pessoal que acha que deve ficar nas versões mais antigas por causa da estabilidade e desconfiança das mais recentes – se mais nada fosse, as actualizações recorrentes resolvem bugs de segurança antes de eles serem um problema ou em resposta a estes.
Tanto o Log4JShell como este foram rapidamente resolvidos com actualizações de segurança em tempo recorde.
“Uma análise preliminar determinou que é necessária a presença de “Spring Beans”, usar “Spring Parameter Binding” e uma “Spring Parameter Binding” deve ser configurada para usar um tipo de parâmetro não básico, como POJOs.”
Ah, pronto, assim estou muito mais descansado…