Skip to content
KitploitKITPLOIT
FerramentasBlog
Log in
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Weblogic-CVE-2020-2551-To-Internet — POC para CVE-2020-2551 para usar na Internet | Kitploit
Ferramentas/GitHubGitHub/dido1960/weblogic-cve-2020-2551-to-internet
Análise de VulnerabilidadesExploraçãoExploração de Aplicações WebTestes de PenetraçãoAprendizado e EducaçãoDesenvolvimento de Payloads
GitHubdido1960/weblogic-cve-2020-2551-to-internet

Weblogic-CVE-2020-2551-To-Internet

POC para CVE-2020-2551 para usar na Internet

Ver Repositório
2272há 6 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Weblogic-CVE-2020-2551-To-Internet

CVE-2020-2551 POC para usar na Internet

  • POC de teste (pode ser usado para testes externos)

    python CVE-2020-2551.py [HOST] [IP]

  • Tentativa de modificar o codebase para carregamento remoto de classes (falhou)

    python CVE-2020-TEST.py [HOST] [IP]

Breve discussão sobre a vulnerabilidade weblogic CVE-2020-2551 e construção de POC externa

(Publicado pela primeira vez no Anquanke, link original)

0x00 Conceitos básicos

Para aprender esta vulnerabilidade, são necessários alguns conhecimentos prévios, como CORBA e RMI.

Uma breve visão geral:

CORBA é um conjunto de padrões técnicos desenvolvidos pela OMG para aplicações distribuídas, onde o IDL é usado para suporte multilíngue e a comunicação entre cliente e servidor utiliza o protocolo IIOP.

RMI é outra tecnologia de aplicação distribuída. Em JAVA, pode ser simplificada com JNDI, e o cliente e servidor comunicam-se usando o protocolo JRMP. No entanto, no weblogic, o RMI usa o protocolo T3, sobre o qual já foram divulgadas várias vulnerabilidades anteriormente.

RMI-IIOP combina as vantagens de RMI e CORBA, implantando aplicações RMI através do protocolo IIOP.

A documentação oficial também menciona:

Os objetos do servidor RMI podem usar o protocolo IIOP e comunicar-se com objetos cliente CORBA escritos em qualquer idioma

0x01 RMI-IIOP

Deixando o weblogic de lado por enquanto, vamos primeiro focar em como criar um exemplo de RMI-IIOP:

O código do cliente pode ser consultado no projeto de teste do artigo Java: RMI, JNDI, LDAP, JRMP, JMX, JMS – Parte 1. Você pode compilar HelloClient e HelloServer por conta própria ou usar os já compilados do projeto de teste.

Inicie o servidor de nomes na linha de comando (nativo do Java):

start orbd -ORBInitialPort 1050

Inicie o servidor HelloServer na linha de comando e configure a depuração remota. Para saber como usar o IDEA para depuração remota, consulte o método mencionado no início deste artigo.

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 HelloServer

Claro, você também pode pular a depuração remota e apenas executar diretamente:

java HelloServer

Inicie o cliente na linha de comando:

Java HelloClient 

Neste momento, a calculadora será exibida. Se a depuração remota for bem-sucedida, você verá a seguinte pilha de chamadas:

O comando é executado em EvilMessage.readObejct()

Observação: Artigos sobre instalação e depuração do weblogic

E quanto ao RMI-IIOP no weblogic? O artigo Sobre RMI-IIOP em Java menciona a exploração do RMI-IIOP do weblogic. Com base nele, realizei algumas pesquisas. O artigo Usando RMI sobre IIOP do WebLogic aborda várias formas de usar o cliente RMI-IIOP do weblogic, incluindo:

  1. Cliente RMI independente (com JNDI, sem usar nada do weblogic)
  2. Cliente WebLogic
  3. Clientes J2EE
  4. Clientes CORBA/IDL

A diferença entre as duas primeiras parece ser apenas a configuração de JNDI_FACTORY

Anteriormente, ao estudar a desserialização T3 do weblogic, implantei uma aplicação HelloServer no weblogic, que possui o método sayhello() utilizável. Tentei chamá-lo com as duas configurações de JNDI_FACTORY e consegui chamar sayHello() com sucesso usando a segunda JNDI_FACTORY

Modifiquei então o POC do protocolo T3 do weblogic, basicamente alterando RMI para IIOP. A cadeia de exploração jtaTransactionManager foi executada com sucesso, enviando uma requisição jrmp para o jrmplisten local

Observando o tráfego, ao chamar o método remove(), é enviada uma requisição remove__java_lang_Object, com dados maliciosos no tráfego, mas o cabeçalho mágico aced não foi encontrado

Supõe-se que o servidor faça uma análise especial antes de desserializar os dados. Observando a pilha de chamadas, a segunda metade da cadeia de execução é muito semelhante à cadeia de execução do RMI-IIOP nativo. A primeira metade é acionada a partir de CDRInputStream.read_value(), enquanto aqui é acionada a partir de IIOPInputStream.read_value() do weblogic. (O ponto read_value também foi mencionado na apresentação de 2019)

Aqui, a requisição primeiro é tratada por clusterableServerRef.invoke() e, dependendo do invoker, chama this.invoker.invoke(). Em seguida, é chamado Mejb_dj5nps_HomeImpl_WLSkel.invoke(). Como a operação é "remove", entra no branch case 6 e chama IIOPInputStream.readObject(). No método read_value(), os dados do IIOPInputStream são analisados e a desserialização é acionada. Este é o POC que utiliza o método remove()

0x02 CVE-2020-2551

A análise do mestre Lucifaer [artigo](https://lucifaer.com/2020/02/25/WebLogic WLS核心组件RCE分析(CVE-2020-2551)/?from=timeline&isappinstalled=0#2-2-Weblogic解析流程) menciona o uso do método bind() para exploração, que também é a forma principal de exploração na Internet. Vamos acompanhar a pilha de chamadas

Como antes, a requisição primeiro é tratada por clusterableServerRef.invoke() e, dependendo do invoker, chama this.invoker.invoke(). Aqui, é chamado CobraServerRef.invoke(), e então em _NamingContextAnyImplBase._invoke(), como va1 é "bind_any", entra no branch case 0 e chama IIOPInputStream.read_any(). Em seguida, ainda chamará IIOPInputStream.read_value() para acionar a desserialização. Antes foi dito que o cabeçalho mágico aced não era encontrado no tráfego, porque IIOPInputStream possui seu próprio método de análise. O formato hex-value do IIOPInputStream é o seguinte, incluindo o nome da classe e informações de campo:

No final, o método readObejct() da classe maliciosa é chamado

Baixar ferramenta