TAGS
En esta serie de entradas de blog, Check Point vulnerabilidad investigador Netanel Rubin cuenta una historia en tres actos - que describe su largo camino de fallas y vulnerabilidades en WordPress núcleo descubiertos, lo que conduce desde una de sólo lectura usuario suscriptor ', a través de la creación, edición y la supresión de puestos de trabajo, y todo el camino a la realización de la inyección de SQL y persistentes ataques XSS, el 20% de la de Internet más populares.
Resumen ejecutivo
Un número de vulnerabilidades críticas existe en instalaciones de WordPress por defecto, lo que permite el compromiso potencial de millones de sitios web en vivo.
MITRE ha asignado CVE-2015-5623, CVE-2015-2213, CVE-2015-5714, CVE-2015-5715, CVE-2015-5716 como identificadores para estas vulnerabilidades. * CVE-2015-2212 fue marcado como duplicado de CVE-2015 a 5623.
La primera vulnerabilidad en esta secuencia (CVE-2015-5623) fue parcheado en una versión de seguridad de WordPress reciente (4.2.3).
Se insta a los administradores del sitio para aplicar actualizaciones de seguridad ya que se liberan (en caso de actualización automática se ha desactivado).
Para más actualizaciones por favor, siga nuestro blog, así como los avisos de seguridad próximas WordPress.
desarrolladores de WordPress son dignos de elogio por sus esfuerzos para mantener este tipo de software complejo en este nivel de seguridad, teniendo en cuenta específicamente la presencia de la notoriamente gatillo fácil pies arma llamada PHP. Verificar los investigadores de vulnerabilidades de Point menudo se dirigen a plataformas de alto perfil, tratando de mejorar la seguridad de software común. Resultados son presentados a los vendedores de software antes de la divulgación pública, con el fin de proporcionar una solución tan pronto como sea posible, lo que contribuye a la seguridad de los usuarios de todo el mundo. Los clientes de Check Point también reciben protecciones preventivas a través de nuestras líneas de productos (de vez en cuando antes de un arreglo vendedor se libera). Es, por lo tanto, no es de extrañar que decidimos auditar WordPress, lo que resulta en nuestro descubrimiento de estos temas críticos.
Tenemos la intención de liberar la descripción técnica de las vulnerabilidades sólo después de WordPress han dado a conocer las correcciones para cada tema. El equipo de WordPress ha sido sensible y alerta; que están trabajando en proporcionar correcciones confiables para todos los problemas comunicados. Desde CVE-2015-5623 fue parcheado en 4.2.3, podemos presentamos nuestra primera parte de la caza vulnerabilidad trilogía.
Parte 1 - "Identidad"
WordPress utiliza una rica y extensible, donde cada usuario se le asigna un papel, que van desde el suscriptor privilegiada más bajo a la omnipotente Superadministrador.
Nuestra superficie de ataque comienza con el entendimiento de que incluso los suscriptores pueden acceder al panel de control del administrador de WordPress, que se encuentra en el directorio '/ admin'. Ellos tienen opciones muy limitadas para controlar en comparación con los administradores, por ejemplo, tal como se determina por sus respectivos privilegios.
De manera predeterminada, sólo los suscriptores se les asigna el 'read_page' limitado y los privilegios de los read_post ', que les permite leer las páginas y mensajes. Los administradores, por el contrario, tienen todos los privilegios disponibles y se pueden crear / editar los mensajes, subir archivos y gestionar la configuración.
WordPress comprueba los privilegios del usuario que ha entrado cada vez que intentan realizar una acción mediante la función 'current_user_can ()'.
'Current_user_can ()' recibe la capacidad solicitada y lo asigna al privilegio real el usuario necesita con el fin de acceder a la acción. Se lleva a cabo mediante una llamada al que 'map_meta_cap () "función con la capacidad como un argumento, que devuelve una matriz con los privilegios reales necesarias para ejecutar esa acción.
Entonces, 'current_user_can ()' bucles a través de esa matriz y comprueba si el usuario tiene esos privilegios.
A medida que los atacantes, comencemos con la suposición de que tenemos un usuario suscriptor. Es común que los sitios web de WordPress para permitir el registro de usuario libre ( 'cualquiera puede registrar'), el impago de la nueva función de usuario de suscriptor. Como suscriptores, sólo podemos leer páginas y mensajes, pero a medida que los atacantes, queremos hacer algo un poco más interesante que eso.
Observemos un extracto de la 'map_meta_cap) (' código para examinar cómo se asignan capacidades en privilegios reales.
Como podemos ver, el cheque 'edit_post / edit_page "capacidad valida el mensaje comprobando si el ID del mensaje que hemos entrado existe (resaltado). La parte interesante es lo que sucede cuando no es - el cheque no establece ninguna capacidad en $ tapas y la matriz se devuelve vacío. Puesto que no hay juego de capacidades, la función actúa como si no necesitamos cualquiera y devuelve verdadero.
Eso significa que, en teoría, podemos omitir las comprobaciones de capacidad con una ID de mensaje no válida. Para explotar eso, necesitaríamos código que llama a esta comprobación y no validar la identificación del mensaje antes de la llamada. Por desgracia no hay muchos casos en los que esto es cierto. Un lugar importante, sin embargo, es el 'edit_post () "función.
Esta función es responsable de actualizar un poste. Se analiza la entrada para la actualización, añade los metadatos solicitados, inserta el formato, y por lo general lo hace todo el trabajo pesado antes de actualizar realmente la entrada de mensaje en la base de datos. Una vez terminada la función de análisis de la entrada, se llama 'wp_update_post ()' que es responsable de la actualización del puesto solicitado en el PP, entre otras cosas de menor importancia, tales como la definición de los valores predeterminados para las propiedades.
Aunque 'edit_post ()' no validar nuestro id de mensaje, 'wp_update_post ()' hace. Esto significa que incluso si el privilegio bypassed marque la primera vez, la segunda vez se producirá un error porque nuestro ID no existe en la base de datos. Aunque no podemos editar mensajes reales en el PP, que todavía puede obtener procesados a través de casi todo el código en 'edit_post'.
Vamos a echar un vistazo a los datos interesantes de ese código:
Como puede verse, además del tipo de mensaje que se establece por el puesto de salir, podemos controlar cualquier valor dentro de '$ post_data'. Eso significa que (aunque no es visible en el código pegado) podemos intentar actualizar los metadatos mensajes 'o cambiar las taxonomías, que ampliarían significativamente nuestra superficie de ataque.
Para que eso ocurra, primero tenemos que llegar a esa función. Hay varios lugares que llaman, pero esos lugares, ya sea comprobar las otras capacidades o comprobar que existe el puesto que estamos tratando de corregir. Eso nos deja con una sola opción de usar - la página 'post.php' admin que utiliza el código siguiente:
Inicialmente, este código parece perfecto para nosotros - no hay capacidades de verificación, ninguna validación posterior identificación, justo lo que necesitamos. Sin embargo, otro problema aflora con el 'check_admin_referer ()' llamada a la función. Esta función comprueba si hay un token CSRF específica que se ha dado a nosotros por el sistema. Este token utiliza de hash generado al azar del servidor y la hora actuales, que al parecer no se pueda adivinar o alterado por un atacante.
A fin de que podamos acceder a 'edit_post ()' primero tenemos que conseguir este token. Podemos ver en el código que el testigo de los sistemas de espera que tiene el formato de 'Add [POST_TYPE]', donde POST_TYPE es el tipo del puesto que estamos tratando de corregir.
Estamos tratando de pasar por alto las capacidades de verificación, lo que significa que estamos utilizando un ID de mensaje que no existe, lo que crea una acción simbólica de 'Add', como un puesto que no existe no tiene un tipo de mensaje. Por suerte para nosotros, el código primero intenta recuperar el identificador del mensaje de la 'GET' parámetro HTTP "post", y sólo si está vacío, entonces intenta obtener de campo 'Post'. Eso crea la oportunidad interesante para enviar 2 ID de post - uno en el parámetro 'GET' que es un identificador de mensaje válido, y uno en el parámetro "post" que no es válido, que nos permite utilizar tanto la cadena correcto token y de derivación de las capacidades comprobar.
Ahora que podemos utilizar la cadena de contadores "add-post", sólo tenemos que encontrar el código accesible que va a generar esa señal. Aunque esta tarea parece sencilla, nuestra falta de capacidades limita considerablemente el acceso a otras acciones. Una vez más, todo lo que necesitamos era uno de estos centros, que fue de hecho encontrar en el 'wp_dashboard_quick_press () "función. Este código, entre otras acciones, genera un token de administrador válida.
El primer problema es fácil - con el fin de convertirse en autor de un post todo lo que tenemos que hacer es crear uno. Para que esto suceda todo lo que tenemos que hacer es llamada 'wp_dashboard_quick_press ()', tal como lo hicimos cuando creamos nuestra ficha. Además de crear el token de administrador, la función también comprueba si un auto-proyecto se ha creado previamente para el usuario actual. Si no se detecta ningún proyecto, la función llama a la 'get_default_post_to_edit ()', que contiene el código siguiente:
Como puede verse, el código recupera el título de la entrada, el contenido y extracto de los parámetros de la petición, y luego, si se le ordena, crea el cargo en el PP. La convocatoria de 'wp_insert_post ()' no incluye un autor posterior, por lo que el sistema asume que el autor debe ser el usuario actual. Aunque la variable "$ create_in_db 'está dispuesto a ser falso como predeterminado, en nuestro caso' wp_dashboard_quick_press () 'le asigna el valor" verdadero "y por lo tanto crea la auto-proyecto en el PP.
Ahora que tenemos un mensaje en la base de datos con nosotros, como los autores de correos, necesitamos cambiar ese estado de la entrada a 'basura'. Ahora tenemos que utilizar un poco de magia negro.
Cuando entramos en 'edit_post ()' el ID del mensaje que estamos editando no debe existir en la base de datos de otro modo las capacidades de comprobación fallará y la ejecución del script va a terminar, pero cuando entramos en 'wp_update_post ()' (a cargo de cambiar el mensaje en DB) el ID del mensaje debe ser válido y existir en la base de datos de otro modo la función devolverá con un 'post no existe "error. ¿Cómo podemos cumplir con estas 2 condiciones contradictorias al mismo tiempo?
Fácil. Hemos echo una carrera condiciones.
Cuando entramos en 'edit_post ()' vamos a utilizar el ID de la próxima entrada que se creará. A medida que los identificadores se incrementan auto, podemos fácilmente "adivinar" que, dada la identificación del último mensaje existente puede ser entendido fácilmente. En ese momento nuestra ID no existirá en el PP y vamos a pasar la comprobación de la capacidad sin ningún problema. Entonces, mientras esta función se ejecuta, vamos a enviar inmediatamente otra solicitud de creación de un nuevo proyecto rápida, según lo demostrado anteriormente, con el fin de crear la ID en el PP. Una vez 'edit_post ()' van a llamar 'wp_update_post ()', ir a buscar el palo de la BD, existirá y el código continuará, sin sospechar nada. J
La pregunta sigue siendo, ¿cómo podemos enviar 2 solicitudes diferentes (Edit Post seguido de la creación de correos), en un momento tan cuidadosa para que esta táctica funcionará. Obviamente, hay que retrasar la ejecución del script.
Veamos el 'edit_post ()' código de nuevo:
Podemos ver que la variable '$' términos, controlado por nosotros, se convierte en una matriz mediante su división usando una coma ( ',') en caso de que sea una cadena. Posteriormente, el código recorre esa matriz, el tratamiento de cada elemento como un nombre de taxonomía, y trata de buscarla a la base de datos utilizando una instrucción "SELECT".
A pesar de todos los "Seleccionar" declaración lleva un par de microsegundos en un servidor bien administrada, de gran alcance, ya que en realidad podemos enviar 16MB (límite duro PHP para el parámetro de un "post") de los términos a buscar, en realidad podemos ejecutar alrededor de 16 millones tales consultas que se llevarán a un buen montón de tiempo para su ejecución. En mi lugar vacío DB situada en mi localhost, impulsado por 1 GB de RAM y un procesador i7, sólo se tarda alrededor de 100 mil consultas para causar un retardo de 30 segundos.
Esto ahora nos otorga una muy poderosa influencia determinista, para explotar nuestra condición de carrera con, sin embargo, nuestro trabajo no ha terminado y todavía tenemos un par de cosas que hacer antes de explotar al máximo esta vulnerabilidad en el menor determinista en cada instalación de WordPress en el mundo .
Debido a que estamos llamando 'wp_dashboard_quick_press ()' con el fin de recuperar el token de administrador que se necesita para que el código para llamar a 'edit_post ()', creamos realmente un proyecto rápido en el proceso. Como he mencionado anteriormente, 'wp_dashboard_quick_press ()' sólo crea un proyecto si no lo es ya, y ya que tenemos que llamar a esa misma función otra vez con el fin de crear nuestro puesto, mientras 'edit_post ()' se retrasa, ese proceso no ocurrió.
POCO
Administrador de recuperación de testigo / creación de post
Condición de carrera
.
