dido1960/weblogic-cve-2020-2551-to-internetCVE-2020-2551 POC para usar en Internet
POC de prueba (se puede usar en redes externas)
python CVE-2020-2551.py [HOST] [IP]
Intento de modificar el codebase para cargar clases remotas (fallido)
python CVE-2020-TEST.py [HOST] [IP]
(Publicado originalmente en Anquanke, enlace original)
Para estudiar esta vulnerabilidad se necesitan algunos conocimientos previos, como CORBA y RMI.
Breve resumen:
CORBA es un estándar técnico definido por OMG para aplicaciones distribuidas, que utiliza IDL para soporte multilenguaje y se comunica entre cliente y servidor mediante el protocolo IIOP.
RMI es otra tecnología para aplicaciones distribuidas; en Java se puede simplificar su uso con JNDI, y la comunicación cliente-servidor utiliza el protocolo JRMP. Sin embargo, en weblogic, RMI usa el protocolo T3, sobre el cual ya se han reportado varias vulnerabilidades.
RMI-IIOP combina las ventajas de RMI y CORBA, desplegando aplicaciones RMI sobre el protocolo IIOP.
La documentación oficial también menciona:
Los objetos servidor RMI pueden usar el protocolo IIOP y comunicarse con objetos cliente CORBA escritos en cualquier lenguaje.
Dejando de lado weblogic por ahora, primero veamos cómo escribir una instancia de RMI-IIOP:
El código cliente se puede referir al proyecto de prueba en el artículo Java: RMI, JNDI, LDAP, JRMP, JMX, JMS (Parte 1). Se puede compilar HelloClient y HelloServer manualmente, o usar los ya compilados en el proyecto de prueba.
Iniciar el servidor de nombres desde la línea de comandos (incluido con Java):
start orbd -ORBInitialPort 1050
Iniciar el servidor HelloServer desde la línea de comandos con depuración remota. Para saber cómo hacer depuración remota con IDEA, consulta el método mencionado al inicio de este artículo.
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 HelloServer
Por supuesto, también se puede ejecutar directamente sin depuración remota y ver el resultado:
java HelloServer
Iniciar el cliente desde la línea de comandos:
Java HelloClient
En ese momento aparecerá la calculadora. Si la depuración remota funciona correctamente, se puede ver la siguiente pila de llamadas:
Ejecución del comando en EvilMessage.readObject()
Nota al margen: artículos sobre la instalación y depuración de weblogic.
¿Y qué hay del RMI-IIOP en weblogic? En el artículo Acerca de RMI-IIOP en Java se menciona la explotación de RMI-IIOP en weblogic. Sobre esa base se realizaron algunas investigaciones. Using WebLogic’s RMI over IIOP explica varias formas de usar clientes RMI-IIOP en weblogic, incluyendo:
La diferencia entre los dos primeros métodos parece ser solo la configuración de JNDI_FACTORY.
Anteriormente, al estudiar la deserialización T3 en weblogic, desplegamos una aplicación HelloServer en weblogic que tenía un método sayhello() explotable. Se intentó llamarlo con dos configuraciones de JNDI_FACTORY, y con la segunda se logró invocar exitosamente sayHello().
Entonces modificamos el POC del protocolo T3 de weblogic, básicamente cambiando RMI por IIOP, y se constató que la cadena de explotación jtaTransactionManager se ejecutó correctamente, enviando una solicitud JRMP al jrmplisten local.
Observando el tráfico, al invocar el método remove(), se envía una solicitud remove__java_lang_Object con datos maliciosos en el tráfico, pero no se encontró el magic header "aced".
Se supone que en el servidor se realiza un análisis especial antes de deserializar los datos. Observando la pila de llamadas, se ve que la segunda mitad de la cadena de ejecución es muy similar a la del RMI-IIOP nativo; la diferencia es que la primera parte se dispara desde CDRInputStream.read_value(), mientras que aquí se dispara desde weblogic.IIOPInputStream.read_value(). (Este punto read_value también fue mencionado en la charla de 2019).
Aquí la solicitud primero es manejada por clusterableServerRef.invoke(), que según el invocador llama a this.invoker.invoke(). Luego se invoca a Mejb_dj5nps_HomeImpl_WLSkel.invoke(), y como es "remove", entra en el caso 6 y llama a IIOPInputStream.readObject(). En el método read_value() se analizan los datos de IIOPInputStream y se dispara la deserialización. Este es el POC que explota el método remove().
El análisis del maestro Lucifaer en su [artículo](https://lucifaer.com/2020/02/25/WebLogic WLS核心组件RCE分析（CVE-2020-2551）/?from=timeline&isappinstalled=0#2-2-Weblogic解析流程) menciona el uso del método bind() para la explotación, que también es la forma principal utilizada en Internet. Sigamos la pila de llamadas.
Al igual que antes, la solicitud primero es manejada por clusterableServerRef.invoke(), que según el invocador llama a this.invoker.invoke(). Aquí se invoca a CobraServerRef.invoke(), y luego en _NamingContextAnyImplBase._invoke(), como va1 es "bind_any", entra en el caso 0 y llama a IIOPInputStream.read_any(). Más adelante también se llama a IIOPInputStream.read_value() para disparar la deserialización. Antes se dijo que no se veía el magic header "aced" en el tráfico, porque en IIOPInputStream hay un sistema de análisis propio. La representación hex-value de IIOPInputStream es la siguiente, que incluye el nombre de la clase e información de los campos:
