PDF de programación - Explotación de Plugins Wordpress

PROYECTO WORDPRESSA

Juan Manuel Fernández (The X-C3LL)




Me alegra que haya llegado el momento de compartir es-
tas líneas escritas por The-Xc3ll, lo conocí en persona en
la RootedCon 2k13 y posteriormente más personalmente
en Navajas Negras. No pude contener mis ganas en pe-
dirle que escribiera algo sobre exploiting en Wordpress
para este proyecto. Jorge Websec









Licenciado en Biología por la Universidad de Salamanca, especiali-
dad de biología fundamental y biotecnología. Desde 2006 ha estado inves-
tigando y realizando auditorias en entornos web como hobbie. Actual-
mente publica en http://blog.0verl0ad.com

Empezó en el entramado mundo de la seguridad informática investi-

gando por su cuenta, de una forma autodidacta. Utilizando para aprender
y compartir los foros y el IRC pudo desarrollar su camino como profesional
en pruebas de intrusión (aparte de leer un montón como todos). Especiali-
zado en auditorias de seguridad web nos trae una guía de como auditar
plugins en wordpress.











Esta obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0





Unported.

pág. 2 || www.wordpresaquantika14.com || [email protected]






Vamos a utilizar la siguiente estructura para la mejor comprensión.

1. Nombre de plugin y vulnerabilidad.
Información sobre el plugin.
Breve descripción del código.

1.1.
1.2.

2. Vulnerabilidades
3. Explotación
4. Solución

Los plugins de esta edición son:

1. NOSpamPTI 2.1 Wordpress Plugin … pag 4
2. Wordpress WP-SendSMS Plugin 1.0 … pag 9
3. WORDPRESS SHOPPING CART 8.1.14 … pag 16
4. WORDPRESS SEO-WATCH PLUGIN 1.4 … pag 22

Todos estos plugins tienen sus respectivas vulnerabilidades y autores que las encontraron.
Pueden verlas en www.exploit-db.com o www.1337day.com Nosotros solo vamos a explicar
cómo auditarlas.

Podrás practicar todo desde Wordpressa LAB v1.5. Puedes descargártelo de la misma página
que te descargaste este PDF.



pág. 3 || www.wordpresaquantika14.com || [email protected]






NOSpamPTI es un plugin de wordpress diseñado a evitar la publicación de



comentarios generados automáticamente por bots. Para tal cometido añade una
prueba-reto basada en responder una suma de dos números naturales comprendidos
entre el 1 y el 4. Posteriormente el plugin comprueba si la respuesta dada coincide con
la esperada. De no coincidir el plugin interpreta que el mensaje ha sido generado por
un programa automático, no se trata de un humano, y eliminar el mensaje.



Es la función encargada de generar la suma y añadirla al formulario original

El plugin posee un archivo PHP principal llamado nospampti.php que posee



únicamente 2 funciones.

*challenge_form():


para el envío de comentarios. Junto al input encargado de recoger la respuesta ante
el reto, también se añade un input tipo “hidden” que contiene el hash md5 de la
respuesta correcta (se resalta en rojo por la importancia que tiene a la hora de hacer
un bypass a la protección)


*challenge_check($comment_id):


Es la función encargada de comprobar si la respuesta del reto es la correcta. En
ella se hace una comprobación con un “if” entre el hash md5 de la respuesta que envió
el usuario y el contenido del campo hidden, de tal forma que si coincide el comentario
se publica y si no éste es eliminado de la base de datos inmediatamente.



Este plugin es vulnerable a Time-based SQL injection y, además, la supuesta



protección que proporciona es fácilmente evadible por parte de los bots.

-Time-based SQL injection:


podemos definirlas como inyecciones de código malicioso dentro de las sentencias

Las SQL injection (abreviadas a partir de ahora como SQLi) de forma genérica

pág. 4 || www.wordpresaquantika14.com || [email protected]



En el caso concreto de las “Blind SQLi” el atacante no puede ver de forma

Si observamos el código de nospampti.php nos damos cuenta de que no existe

Inicialmente podemos pensar que se trata símplemente de una SQLi normal o a

normales que ejecuta una aplicación al interactuar con una base de datos. Este código
malicioso perturba el normal funcionamiento de la sentencia, permitiendo a un
atacante ejecutar de forma arbitraria lo que desee. Se produce por tomar directamente
las variables que toman valores proporcionados por el usuario, sin realizar ningún
filtrado.


directa el resultado de su inyección, sino que tiene que proceder a una “boolenización”
de las sentencias, observando si en tras inyectar se obtiene un valor True o uno
False. Normalmente esto se observa cuando carga o deja de cargar una parte de la
web (si no carga es que la sentencia ha devuelto un valor False; si carga es un True).
De esta forma podemos ir poco a poco deduciendo el nombre de tablas, columnas, etc.



ningún tipo de protección, y se realiza una sentencia a la base de datos de forma
directa con el valor procedente de la petición POST que se realiza al enviar un
comentario:

$count = $wpdb->get_var("select count(*) from $wpdb->comments where
comment_post_id = {$post_id} and comment_approved = '1'");



ciegas clásica, pero si observamos el código en conjunto observaremos que su
explotación requiere del uso de técnicas basadas en el timing.

if ($hash != $challenge) {
$wpdb->query("DELETE FROM {$wpdb->comments} WHERE comment_ID = {$comment_id}");
$count = $wpdb->get_var("select count(*) from $wpdb->comments where comment_post_id =
{$post_id} and comment_approved = '1'");
$wpdb->query("update $wpdb->posts set comment_count = {$count} where ID = {$post_id}");
wp_die(__('Sorry, wrong answer.'));
}
}



obtener el mensaje de “Sorry, wrong answer.” independientemente que la inyección
que nosotros le pasemos a la base de datos devuelva un valor True o False. Por lo tanto
debemos de recurrir al uso de funciones que metan un retardo de un tamaño
suficientemente sensible si la sentencia devuelve True, de tal forma que podamos
discriminar el resultado de la inyección a través del tiempo que tardemos en tener una
respuesta.


porque para su explotación recurrimos a retardos de tiempo


“hidden” en el formulario para el envío de comentarios.



Si observamos la última línea, resaltada en rojo, veremos que siempre vamos a

Por esta razón se denomina a esta vulnerabilidad “Time-based SQL Injection”:

La variable vulnerable es comment_post_ID y se manda como un campo

pág. 5 || www.wordpresaquantika14.com || [email protected]



Como bonus además este plugin diseñado para evitar los mensajes de SPAM






-Bypass de la protección Anti-Spam:


puede ser bypasseado de múltiples formas, quedando la supuesta protección que ofrece
en entredicho. Observando el código se ve más claro:

$nums = array(rand(1,4), rand(1,4));
$n1 = max($nums[0], $nums[1]);
$n2 = min($nums[0], $nums[1]);
$challenge = ($n1 + $n2);
$hash = md5($challenge);

$question = __("Which the sum of: {$n1} + {$n2}");
$field = sprintf('<p><label for="challenge">%s</label> <input type="hidden" name="challenge_hash"
value="%s" /> <input type="text" name="challenge" id="challenge" size="2" /></p>', $question, $hash);
echo $field;



En primer lugar podemos ver como el reto se compone de únicamente una suma

Como colofón final nos encontramos con que el propio sistema está mal diseñado


de dos números naturales comprendidos entre 1 y 4 (1, 2, 3, 4) por lo que la variedad
de respuestas plausibles es muy limitada. A parte de esto, el hecho de seguir siempre
la misma estructura permite a un spammer generar un bot que busque la cadena
“Which the sum of:” y a continuación leer la suma y calcular el resultado directamente
(esta debilidad está resaltada en rojo).


puesto que la respuesta al reto que se debe de enviar (el hash md5, señalado de color
azul) está implícita en el propio formulario, por lo que un usuario malintencionado
únicamente tendría que hacer un bot que buscase el input de nombre
“challenge_hash”, extrajera el md5 y, en un listado previamente creado (las opciones
son pocas puesto que es la suma de únicamente del 1 al 4) comprobar a qué número
corresponde el hash.



Para la explotación manual de esta vulnerabilidad podemos recurrir a



herramientas que permitan la manipulación del contenido enviado por POST. En este
caso vamos a utilizar el add on para Mozilla Firefox conocido como “Live HTTP
Headers”, que permite el sniffing de las cabeceras HTTP y su manipulación.


damos cuenta de un detalle que es imprescindible para ponernos en contexto:



Volviendo a revisar el código de la función que posee la consulta vulnerable nos



pág. 6 || www.wordpresaquantika14.com || [email protected]



if ($hash != $challenge) {
$wpdb->query("DELETE FROM {$wpdb->comments} WHERE comment_ID = {$comment_id}");
$count = $wpdb->get_var("select count(*) from $wpdb->comments where comment_post_id =
{$post_id} and comment_approved = '1'");
$wpdb->query("update $wpdb->posts set comment_count = {$count} where ID = {$post_id}");
wp_die(__('Sorry, wrong answer.'));
}
}

El operador de comparación “!=” señalado en azul nos indica que la petición a la
base de datos se ejecutará cuando $hash sea diferente a $challenge. Por lo tanto para
poder inyectar cualquier cosa previamente debemos conseguir esta condición, lo cual
es sencillo: únicamente debemos de tomar una petición HTTP que contenga una
petición POST legítima y proceder a modificar el campo challenge_hash por cualquier
cosa.


Una vez hemos modificado el campo challenge_hash por una cadena aleatoria, a
fin de cumplir el !=, procedemos a realizar las inyecciones. Para introducir los retardos
de tiempo podemos emplear la función SLEEP():









answer.”