¿Se puede aprovechar CVE-2015-4852 contra los servidores de WebLogic después de un equilibrador de carga?

Bien, vamos al punto: la vulnerabilidad CVE-2015-4852 no tiene que ver con el protocolo T3. El problema radica en las rutinas de serialización / deserialización utilizadas por WebLogic y las bibliotecas subyacentes que componen la ruta de clase de Java.

Entonces, solo para aclarar algunos puntos:

• El protocolo T3 se cita porque es un punto de entrada a datos serializados proporcionados por el usuario.
• WebLogic se cita porque viene con el Apache Commons afectado biblioteca y se carga en la ruta de clase cuando se ejecuta WebLogic. Debe actualizarse para que la biblioteca empaquetada afectada también pueda actualizarse. O puedes actualizarlo tú mismo.
• El problema real se encuentra dentro de la propia biblioteca de Apache Commons.

Por lo tanto, respondiendo a su pregunta, sí, su aplicación aún puede verse afectada por las vulnerabilidades de deserialización si el atacante puede encontrar otro lugar para ingresar datos maliciosos serializados . Algunas aplicaciones Java se basan en difícilmente en la serialización. Muchos de ellos también lo envían a través de conexiones HTTP / S codificadas en base64 o con algún otro tipo de codificación. Las aplicaciones Java JSP también hacen uso de Viewstates (base64'd también, aunque utiliza una estructura que difiere de las ASP.NET Viewstates).

Incluso he visto que el módulo HCM (Human Capital Management) de Oracle utiliza la serialización codificada en base64 para definir el título de una página (sí, pude cambiarlo a lo que quisiera, pero en el momento en que lo examiné, no estaba No es muy consciente del funcionamiento interno de las fallas de deserialización)

ACTUALIZACIÓN:

Ha habido algún desarrollo en este tema. No en este CVE en sí, pero algunas personas descubrieron que hay más bibliotecas (también muy comunes) que son vulnerables a toda la cuestión de la serialización / deserialización.

enlace

Desde mi entendimiento de la vulnerabilidad como se menciona aquí enlace , Si puede alcanzar ObjectStream.readObject () de su aplicación Java, será posible explotar esto. Entonces, si tiene una url, por ejemplo example.com/sample y la muestra se refiere al equilibrador de carga como enlace , debe estar a salvo de un weblogic Perspectiva para cualquiera que acceda a example.com y no a host1.

Supongo que todo de lo que debe preocuparse es si su equilibrador de carga permite conexiones t3. Si es así, solicite que sea bloqueado. Como sugiere el documento de Oracle (Doc. ID 2076338.1), bloquee el acceso a t3 y debería ser bueno.

Solo es explotable (diferente a 'vulnerable') si los datos serializados pueden alcanzar su aplicación. En este caso, si el tráfico T3 no se pasa a través de entonces no, no sería explotable a través de esta avenida.

Sin embargo, tenga cuidado, cualquier otra ubicación donde se reciban datos serializados controlados por el usuario es igualmente vulnerable, y esto puede ocurrir a través de http.

CVE-2015-4852 es una vulnerabilidad específica en el software Oracle WebLogic . Se ha descubierto que el protocolo t3 es vulnerable porque puede recibir objetos serializados no confiables de un atacante potencial. Si el protocolo t3 no está conectado a los balanceadores de carga, el tráfico malicioso no se pasa al portal Weblogic evitando la amenaza en este caso.

Sin embargo, las vulnerabilidades serializar / deserializar son una categoría completa de vulnerabilidades . Otros componentes del software Oracle WebLogic pueden ser vulnerables, no solo el protocolo t3. El hecho es que ningún otro componente en WebLogic ha sido identificado como vulnerable.

Por otra parte, las aplicaciones Java estándar o personalizadas servidas por el servidor Oracle WebLogic (u otros servidores de aplicaciones) pueden ser vulnerables a las vulnerabilidades de serialización / deserialización . Aunque no es frecuente pasar objetos serializados a través de HTTP, puede ser posible incluirlos en encabezados, cookies, publicar u obtener datos, etc.

La forma recomendada de saber si su aplicación es vulnerable es:

1. Ir al directorio de aplicaciones
2. grep -R InvokerTransformer.
3. Determine o intercepte el tráfico y busque objetos serializados del usuario a la aplicación:
   • rO0AB (base64)
   • ac ed 00 05 (hexadecimal)
4. Desarrolle una prueba de concepto específica y verifique

Esta no es la forma definitiva de encontrar este tipo de vulnerabilidad, ya que otras formas de explotar las peligrosas llamadas a readObject () pueden descubrirse sin utilizar InvokerTransformer .