Fallo en los productivos de WP

notas-wordpress-500x375Me interesó publicar esta noticia porque se puede aprovechar para iniciar una discusión respecto a los fallos en producción y el impacto que originan.

En este caso en particular, el problema detectado esta vinculado con el CMS WP (WordPress).
Actualmente es el mejor CMS a nivel mundial, y por ende, el más atacado desde hace un buen tiempo.
Si bien hay una gran comunidad de programadores y probadores que trabajan en nuevas versiones para incorporarle seguridad y mejoras de todo tipo, indudablemente el WP ha sido víctima del flagelo de los fallos y hackeos.

A continuación, la nota:

Hace unos días se han reportado cientos de hackeos en sitios basados en wordpress que contenían el script TimThumb en el theme o en algún plugin. En primera instancia, muchas compañías de hosting recomendaron la instalación de algunos plugins de seguridad tales como Akismet, Login Lockdown o Limit Login Attempts. Posteriormente, se supo que el fallo radicaba en el pequeño script timthumb que realiza un resize automático en las imágenes jpg, png y gif, o bien, permite subirlas desde un servidor remoto de sitios web conocidos.

Según el sitio websitedefender.com, la vulnerabilidad consiste en que un atacante es capaz de subir un archivo php y ejecutarlo en nuestro servidor debido a un bug que permite el filtrado de cierto tipo de dominios. El código que permite el dominio de origen para subir imágenes es el siguiente:

// external domains that are allowed to be displayed on your website

$allowedSites = array ( ‘flickr.com’, ‘picasa.com’, ‘blogger.com’, ‘wordpress.com’, ‘img.youtube.com’, );

Resulta que el atacante puede utilizar un dominio tipo hacker.com.blogger.com y el script lo acepta como correcto y permite su inclusión, lo cuál hace que pueda ser subido y ejecutado cualquier tipo de archivo php con código malicioso con el fin de escalar privilegios y hacerse con la cuenta admin de forma inmediata. Esto pone en peligro muchísimos blogs basados en wordpress que tienen themes funcionando con el redimensionado de imágenes o incluso plugins que lo hacen servir.

El impacto de este fallo se ha dado en plugins y themes.
Para los que no saben, los «plugins» son pequeños desarrollos que se pueden incorporar fácilmente al CMS para darle más funcionalidad, mientras que los «themes» son plantillas que se incorporan al CMS como FE (Front End) para permitirle por ejemplo, que ahora cumpla con las condiciones del tipo responsive y que se puede visualizar y navegar en todo tipo de browsers y dispositivos móviles.

A continuación les dejo el enlace para acceder al artículo:

http://www.websitedefender.com/wordpress-security/timthumb-vulnerability-wordpress-plugins-themes/

¿Qué opinan al respecto?
¿Qué tipo de testing se debería hacer para evitar o minimizar este problema?
¿Cómo se pudo haber evitado este fallo?
¿Se podía haber detectado a tiempo en un laboratorio con el ambiente adecuado?

Artículos relacionados

1. TimThumb: Problemas y soluciones para desarrolladores de temas WordPress
TimThumb es un script PHP que redimensiona imágenes de manera dinámica, a menudo incluido en temas y plugins WordPress. Guarda una cache de las imágenes procesadas por razones de rendimiento en su carpeta de cache por defecto, llamada cache, situada a un nivel de carpetas por encima del mismo script. Afortunadamente, TimThumb permite al usuario definir un directorio de cache personalizado con una constante (FILE_CACHE_DIRECTORY) así como un mecanismo para cargar su configuración personalizada (un archivo opcional timthumb-config.php).

Esta configuración facilita un montón de flexibilidad a la hora de usar TimThumb en una web de un cliente. Pero cuando TimThumb viene incluido en un tema o plugin este método de configurarlo no es muy útil. Un ejemplo es WooThemes, que usa TimThumb en todos sus temas, o Elegant Themes (mi preferido), que también los usaba aunque lo está abandonando. Y es que hay situaciones en que el servidor no te permite escribir en subdirectorios de tu carpeta /wp-content/themes/, y en estos casos no te queda otra que usar la localización de la cache por defecto.

El problema es que no hay manera sencilla de solucionar esto de una manera global, que sirva para todos los casos. Crear una carpeta /cache/ en cada uno de los directorios de estos temas y cambiar los permisos (chmod) de los mismos no siempre es posible, aunque siempre hay algún sitio donde subir archivos y que, por defecto, normalmente siempre tiene permisos de escritura del servidor: wp-content/uploads y wp-content/blogs.dir

Fuentes consultadas:
http://ayudawordpress.com/timthumb-problemas-y-soluciones-para-desarrolladores-de-temas-wordpress/
Fuente: http://www.seguridadwordpress.com/importante-vulnerabilidad-en-timthumb-que-afecta-a-plugins-y-themes/

Gus Terrera

Apasionado por el agile testing y la ia.

Deja una respuesta