Aviso de Seguridad: Vulnerabilidad de Inyección del Objeto en WooCommerce

Riesgo de Seguridad: Peligroso
Nivel Explotación: Fácil / Remoto
Puntuación DREAD: 8/10
Vulnerabilidad: Inyección de objetos
Versión Parcheado: 2.3.11

Durante una auditoría de rutina para nuestra WAF, descubrimos una vulnerabilidad deInyección de Objetos peligrosos que podrían, en ciertos contextos, ser utilizado por un atacante para descargar cualquier archivo en el servidor vulnerable.

¿Está Usted en Riesgo?

La vulnerabilidad está presente sólo cuando la opción “Señal de Identidad de Paypal” de WooCommerce se establece. Si es así, su sitio es vulnerable a un tipo de inyección de objetos de la vulnerabilidad, que esencialmente significa que, dependiendo del contexto, el sitio se ejecuta en, puede ser utilizado para hacer una variedad de cosas. Logramos usar una combinación de componentes de WooCommerce y WordPress con un error de programación PHP conocido (CVE-2013-1643) para descargar archivos críticos, archivos como wp-config.php; para los que no conocen, este archivo contiene las credenciales de base de datos y claves secretas de WordPress. Como se ha visto en el pasado, dando a un atacante acceso a estos archivos generalmente se traduce en compromiso del sitio completo.

Vale la pena señalar que incluso si su sitio no se ejecuta en la parte superior de una versión antigua de PHP (un montón de diferentes vectores de ataque de un atacante) podría utilizar en función de lo que los plugins que tiene disponible. También hay un par de otros errores relacionados con el propio PHP que podríamos haber investigado, pero decidimos seguir con CVE-2013-1643 porque está ampliamente documentado y relativamente simple para recrear.

Detalles Técnicos

Todo comienza en el método get_paypal_order de la claseWC_Gateway_Paypal_Response.

El parámetro de la función $custom se pasa directamente a WordPress funciónmaybe_unserialize (), que puede ser utilizado en ataques de inyección de objetos cuando se corre con la entrada directa del usuario.

Como se puede ver en el fragmento de código anterior, el método get_paypal_orderse utiliza con las variables contaminados por $ _REQUEST [‘cm’], lo que significa que cualquiera que acceda a la página en la que se ejecuta el código (cuando alguien visita la página de la order-received del plugin con algunos parámetros específicos establecidos) pueden utilizar este vector para desovar instancias de clases arbitrarias y potencialmente modificar el flujo de ejecución de la aplicación (según las clases que están disponibles en el contexto corriente).

Debido a que este tipo de vulnerabilidad requiere condiciones muy específicas para ser explotadas, decidimos darle una oportunidad y crear una prueba de concepto para demostrar cómo un individuo malintencionado podría utilizar esta vulnerabilidad, junto con CVE-2013-1643, escaparse el archivo de configuración de WordPress wp-config.php.

Fuga de Archivos

Algunos de ustedes ya se habrán dado cuenta, la CVE que se mencionó anteriormente se refiere a algunas cuestiones SOAP / XML, nada relacionado con unserialize () o inyección de objetos como un todo. El truco radica en el hecho de que este error en particular afecta a unos mecanismos de PHP, incluyendo la clase SoapClient. Lo que hace esta clase en particular interesante es el hecho de que contiene un método mágico __call que hace posible que presente una solicitud SOAP a cualquier servidor y analizar el XML resultante por lo que es posible llevar a cabo ataques XXE y descargar archivos desde el servidor.

Con el fin de activar el método __call, teníamos que encontrar un lugar en el código donde podíamos forzar nuestro objeto decodificado para llamar a un método que no existe en la definición de clase original, forzando así el método mágico para disparar. Hemos encontrado lo que buscábamos en clase WordPress PHPMailer, específicamente en el método smtpClose ().

En este escenario, nos unserialize una clase PHPMailer cuya variable SMTPcontendría una instancia SoapClient cuidadosamente elaborado para activar la parte XXE de la explotación. Eso es bueno en teoría, pero teníamos que encontrar una manera de llamar a este método.

.. Tuvimos suerte!

La clase PHPMailer también contenía un destructor que llama al método smtpClose ()! Esto significa que todo lo que tendríamos que hacer para obtener el método mágico__call a ejecutar es crear una instancia de una clase PHPMailer que tiene la variable Mailer conjunto de “smtp”; PHP llamaría sería llamar a los métodos necesarios cuando la ejecución de la escritura corriente termina.

Por último, pero no menos importante, vamos a necesitar la clase PHPMailer presente en el contexto de aplicación cuando nuestra carga útil serializado realiza la llamadamaybe_unserialize (), que no es el caso por defecto. En términos generales, esta clase se incluye cuando WordPress utiliza la función wp_mail (), por tanto tuvimos que encontrar un lugar donde podríamos obligar WooCommerce a enviar un correo electrónico antes de que nuestra carga útil seriada sea no seriada.

Por suerte para nosotros WooCommerce permite a los usuarios restablecer la contraseña perdida de su cuenta, un proceso que requiere el envío de un correo electrónico, exactamente lo que queremos! Además, esta función se engancha muy temprano en la secuencia de arranque de WordPress, que es perfecto para nosotros, ya que va a hacer la clase PHPMailer disponible para unserialization.

Actualizar Tan Pronto Como Sea Posible

Si estás usando una versión vulnerable de este plugin, actualizar tan pronto como sea posible! En el caso de que usted no puede hacer esto, le recomendamos aprovechar nuestra Firewall Sitio Web o tecnología equivalente para tenerlo parcheado virtualmente.

Fuente:https://blog.sucuri.net