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.
Los clientes de Check Point están protegidos contra la secuencia de vulnerabilidad a través de firmas IPS. Prólogo
WordPress es un CMS basado en PHP (Content Management System), en efecto, la plataforma web más prominente en el Internet hoy. Se estima ejecutar más del 20% de 1 millón de mejores sitios web en todo el mundo.
WordPress casos son señalados por los ciberdelincuentes y hackers maliciosos, ya que pueden dar lugar a bases de datos privadas y acceso a la red interna. Un compromiso típico de WordPress se basa en la explotación de vulnerabilidades en un componente complemento obsoleto.
Al ser una plataforma tan popular, WordPress es también una de las piezas más escrutados a nivel mundial de software, en términos de las evaluaciones de seguridad y la investigación de vulnerabilidades, con miles de ojos revisión de nuevas características y correcciones de errores, así como 3 ª parte plug-ins.
De vez en cuando, los investigadores descubren vulnerabilidades en ciertos plug-ins, escrito por terceros y por separado instaladas por los administradores del sitio. Estas vulnerabilidades se publican semanalmente en varios canales, incluyendo la lista de correo "Full Disclosure".
En contraste con estos hallazgos frecuentes en código 3 ª parte plug-ins ", temas de WordPress barebones son raros, ya que los desarrolladores del núcleo de WordPress están bien entrenados para mantener la conciencia de alta seguridad para todo el código liberado. Podemos confirmar que durante nuestra auditoría del código fuente, fuimos testigos de la desarrolladores de 'dejar nada al azar', y la aplicación de múltiples capas de seguridad que protege la mayoría de los tipos de ataque que podríamos imaginar.
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.
La convocatoria de esta función se encuentra, sin embargo, cuando un usuario sin capacidades intenta guardar un nuevo proyecto. Esto se puede ver en el siguiente código:
Como es evidente anteriormente, si un usuario no proporciona una ficha correcta, o se carece de la capacidad de los edit_posts '', la función se activa y recibimos un contador admin 'add-post "válida.
Con esta muestra podemos ahora libremente se procesan en la función 'edit_post', siempre y cuando que la oferta de un puesto de identificación válido.
En este punto podemos crear y añadir metadatos no protegidos a los puestos no existentes, crear y seleccionar taxonomías y varias otras cosas de menor importancia. Aunque esto suena muy bien, es aún muy lejos de nuestro objetivo del atacante - queremos ser realmente capaz de editar un mensaje real, de modo que podemos acceder al código previamente protegido por la capacidad de verificación 'edit_post'.
Vamos a volver a examinar el código de comprobación de la capacidad de:
Tenga en cuenta el código resaltado - si el usuario es el autor del mensaje, y el puesto está marcado como basura, no se necesitan capacidades. Esto marca un camino claro hacia los privilegios de edición. Pero, ¿cómo podemos llegar a ser tanto un autor posterior y establecer su estado a 'basura'?
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ó.
¿Cómo podemos crear un proyecto si se produce alguna ya existe? Pues bien, el proyecto creado por 'wp_dashboard_quick_press ()' hay proyecto común, es en realidad un proyecto rápido (también llamado un guardado automático). Como tal, el proyecto se supone que es sólo una forma temporal de almacenar el texto mensaje en caso de una repentina pérdida de datos. Debido a que estos proyectos son tratados como elementos temporales, consiguen auto borrado dentro de una semana.
Esto significa que tenemos que esperar una semana completa con el fin de explotar nuestra vulnerabilidad, ya que este es el período de tiempo que lleva ese proyecto que desea eliminar. Afortunadamente para nosotros, fichas suelen durar 24 horas, lo que nos permite recuperar los contadores un día antes de la fecha prevista de su eliminación, y utilizarlo con el fin de entrar en 'edit_post ()' después de que el proyecto se elimina.
Finalmente, después de pasar el token de validación, la validación de los privilegios, la validación básica de administración, y la validación posterior identificación, cambiar el estado posterior a 'basura' es tan sencillo como enviar un parámetro HTTP. Gracias a Dios.
La combinación de todos estos desvíos juntos, usamos una cadena de alrededor de una docena de diferentes insectos, un sistema de privilegios defectuosa, y casi todas las hipótesis falsa en el sistema para lograr privilegios de editor parciales. El camino hacia una vulnerabilidad crítica es aún largo, pero en su extremo que se encuentra tanto un SQLi y un XSS, que se describen en las próximas entradas.
POCO
Administrador de recuperación de testigo / creación de post
Condición de carrera
.
