Vulnerabilidad de Inyección de SQL en el NextGEN-Gallery para WordPress

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone

Como parte de un proyecto de investigación de la vulnerabilidad para nuestro Firewall Sucuri (WAF) auditamos varios proyectos de código abierto buscando problemas de seguridad. Cuando se trabaja en el plugin NextGen Gallery Plugin en WordPress, hemos descubierto una vulnerabilidad grave de inyección SQL. Esta vulnerabilidad permite a un usuario no autenticado capturar los datos de la base de datos de sitios web de la víctima, incluido la información confidencial del usuario.

¿Su Sitio Web Está en Riesgo?

Esa vulnerabilidad puede ser explotada por los hackers en dos situaciones:

  1. Si usa el NextGEN Basic TagCloud Gallery en su sitio web, o
  2. Si permite a sus usuarios enviar posts para se revisaren (contribuyentes).

Si su sitio web no se encaja en alguno de estos casos, se encuentra en riesgo.

Este problema existe porque el NextGEN Gallery permitía un input del usuario desinfectado de forma incorrecta en una SQL query preparada para WordPress, que es básicamente lo mismo que añadir el input del usuario en una raw SQL query. Mediante el uso de este vector de ataque, un atacante podría filtrar contraseñas y claves secretas de WordPress en ciertas configuraciones.

Detalles Técnicos

Nunca confíe en el input – esta es la regla de oro que mejora la seguridad de sus clientes. En cada escenario, hay que hacer algunas preguntas simples:

  • ¿Ese input es seguro?
  • ¿Se lo ha sanitizado?
  • ¿Seguimos las reglas específicas de framework y mejores prácticas?

WordPress utiliza la función de PHP vsprintf para preparar instrucciones SQL en $wpdb->prepare(), lo que significa que el SQL statement utiliza una cadena de caracteres de formato y los valores de entrada como sus argumentos. Esto nos lleva a la conclusión de que nunca es una buena idea proporcionar el input del usuario siguiendo los caracteres de formato, ya que no se puede sanitizar contra caracteres que podrían crear directrices arbitrarias válidos de sprintf/printf.

Es por eso que el método específico get_term_ids_for_tags() nos llamó la atención:

Encontramos ese código en nextgen-gallery/products/photocrati_nextgen/modules/
nextgen_gallery_display/package.module.nextgen_gallery_display.php

A partir del código fuente, percebemos que la string $container_idsse crea a partir del input da tag y sus valores no son desinfectados correctamente. Seguros contra la inyección de SQL, pero no impediría la formatación de strings directives/input, lo que puede causar problemas con el método de la abstracción de la base de datos de WordPress prepare().

$wpdb->prepare and sprintf

Desde el código del método prepare, observamos que algunos cambios se ejecutan en el código SQL original. Cuando se encuentra el %s, se lo sustituye por ‘%s’. También vemos que después de realizar los cambios, pasa por la función vsprintf, lo que significa que cualquier diretivas de string de caracteres de formato válidos que se pueden inyectar serán procesados. A partir de la documentación de la función vsprintf de PHP, sabemos que los argumentos de cambio podrían ocurrir, y cuando los inputs sanitizados incorrectamente se agregan a la siguiente cadena de caracteres de formato puede haber algunos problemas:

  1. Un usuario malicioso puede inyectar lo siguiente input al formato string/query:
    [any_text1]%1$%s[any_text2]
  2. La query quedaría así:
    [querycode1][any_text1]%1$%s[any_text2][querycode2]
  3. Cuando pasa al método prepare, se modifica para:
    [querycode1][any_text1]%1$'%s'[any_text2][querycode2]

    (e.g. %s será ‘%s’)

  4. Después que e string del formato resultante pasa por la función vsprintf, el SQL query resultante tendrá el formulario:
    [querycode1][any_text1][first_argument]'[any_text2][querycode2]

Esto significa que vamos a tener un extra . Esto rompe nuestra cadena de caracteres de comillas simples y hace que el raw input[any_text2] sea parte de la propia SQL query.

Tipos de Exploits

A partir del código fuente del plugin, encontramos dos lugares en los que esta función crearía la cadena $container_ids (necesaria para ejecutar el exploit):

  • Al usar el shortcode del tag gallery, que requiere que un usuario autenticado privilegiado haga el ataque.
  • Cuando accediendo tags del NextGEN Basic TagCloudgallery, que visitantes maliciosos pueden hacer para modificar la URL del gallery (desde que el gallery exista en el sitio web).

Con este conocimiento, un atacante no autenticado podría añadir directrices adicionales sprintf / printf al SQL query y utilizar el comportamiento del $wpdb->prepare para añadir el código controlado por el atacante a la query ejecutada.

Lo payloads del ataque final (usando el método TagCloud) serían así:

http://target.url/2017/01/17/new-one/nggallery/tags/test%251%24%25s))%20or%201=1%23

o

http://target.url/2017/01/17/new-one/nggallery/tags/test%251%24%25s))%20or%201=2%23

Conclusión

Este es un problema crítico. Si está utilizando una versión vulnerable de este plugin, actualice lo antes posible.

Si no puede actualizar, recomendamos usar el Firewall Sucuri (o tecnología semejante) para se parchear la vulnerabilidade virtualmente.

Fuente:https://blog.sucuri.net/

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone