Category: XSS

Categories
Seguridad Sql Injection Web WordPress XSS

WordPress: Lista de plugins no recomendados

A continuación muestro una pequeña lista de plugins para WordPress que tienen problemas de seguridad o rendimiento y por lo tanto, no deberían ser utilizados tal cual son descargados; si tienen instalado alguno de éstos, pueden desactivarlos, ponerse en contacto con el autor o solucionar los problemas por sus propios medios - corregí algunos plugins que menciono, pero muchos de los cambios que hago, son específicos para este blog 🙁

  • Acronym Replacer Revisited: Además de los problemas de rendimiento anteriormente descritos, es vulnerable a ataques XSS y CSRF, gracias a este último es posible insertar y ejecutar código PHP arbitrario.
  • Spam Karma 2: Me recomendaron este plugin hace poco y a pesar de lo bueno que parece ser, finalmente lo descarté porque es vulnerable a ataques XSS, CSRF y SQL Injection - ya se imaginarán lo que puede pasar con los datos de sus blogs.
  • Adsense-Deluxe: No realiza ninguna protección contra ataques CSRF, usando este último es posible persistir HTML arbitrario (¿XSS o HTML Injection?).
  • Google Analytics: Falla al intentar protegerse contra ataques CSRF (no es suficiente usar la función check_admin_referer) y cae en el mismo problema que Adsense-Deluxe.
  • catcloud: Ídem al problema que tiene Adsense-Deluxe.
  • Google (XML) Sitemaps: Ídem al problema que tiene Adsense-Deluxe.
  • Related Posts: Ídem al problema que tiene Adsense-Deluxe. Si se usa la versión que incluye el soporte para páginas no encontradas (404), entonces es posible hacer SQL Injection en los blogs que lo usen.
  • Audio player: Ídem al problema que tiene Adsense-Deluxe.
  • wp-cache 2.1: En realidad pongo esta versión del plugin porque Dreamhost todavía sigue instalando la versión vulnerable de wp-cache, que tiene un problema similar a Adsense-Deluxe. Pueden actualizar manualmente a la versión 2.1.1 para corregir este fallo.
  • Pagebar: Es vulnerable a ataques XSS en versiones recientes de WordPress

Imagino que esta lista puede crecer indefinidamente 🙂 pero los que muestro aquí, son aquellos con los que tuve/tengo contacto en este blog y en otros que ayudé a poner a punto.

Nota: Por obvias razones, no voy a publicar detalles o pruebas de concepto de los problemas de seguridad. Por otro lado, por falta de tiempo, sólo me puse en contacto con algunos autores.

A excepción de wp-cache, los problemas mencionados están presentes en las últimas versiones de los plugins.

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
Expresiones Regulares PHP Seguridad XSS

PHP: Uso adecuado de expresiones regulares

Actualización 17/04/2007: Al parecer el problema descrito ya no es válido en versiones recientes de PHP.

PHP incluye el soporte para expresiones regulares usando una sintáxis compatible con Perl (preg_match, preg_replace, preg_split, etc) y también las expresiones con sintáxis POSIX extendido (ereg, eregi, ereg_replace, eregi_replace, etc).

En esta oportunidad no hablaré de los problemas derivados del abuso o uso inadecuado de las expresiones regulares, sino un problema más específico para aquellos que usan las funciones POSIX-extendido de PHP, sobre el cual existe la siguiente advertencia en el manual de PHP:

Estas expresiones regulares no son seguras con material binario. Las Funciones PCRE lo son.

Bien, veamos un ejemplo en el que por usar este tipo de funciones, una aplicación puede llegar a sufrir problemas de XSS o Inyección de SQL (si es que sólo se usa este tipo de cosas para validar los parámetros):

php:

<?php
// re.php

header('Content-type: text/html; charset=utf-8');

if ( eregi('^[a-z0-9]{4}$', $_GET['key']) ) {
        echo $_GET['key'];
} else {
        echo 'Caracteres no válidos';
}

// ...
?>

La expresión regular definida para validar el parámetro key supuestamente debería considerar sólo aquellos valores constituidos por cuatro letras y/o números, pero debido a que éstas funciones no son seguras con material binario, es posible saltar fácilmente esa validación añadiendo el caracter \0 (fin de cadena en C/C++).

Por ejemplo, para el siguiente valor de key:

php:

<?php

header('Content-type: text/html; charset=utf-8');

$_GET['key'] = 'test' . chr(0) . '<script>alert("Texto no tomado en cuenta")</script>';

if ( eregi('^[a-z0-9]{4}$', $_GET['key']) ) {
        echo $_GET['key'];
} else {
        echo 'Caracteres no válidos';
}

// ...
?>

Se mostrará en el navegador lo siguiente:

code:

test?<script>alert("Texto no tomado en cuenta")</script>

Para conseguir este mismo resultado desde el navegador, sólo basta usar %00 en la URL para representar el caracter \0: key=test%00<foo>.

Si están usando este tipo de funciones, ya están advertidos de los problemas que podrían tener si se les olvida la recomendación del manual de PHP.

Categories
Seguridad Web WordPress XSS

Problemas de seguridad con WordPress 2.x y el plugin pagebar

Debido a unos cambios hechos en la función get_pagenum_link de las ramas 2.0 y 2.1 de WordPress, varios blogs que usan el plugin pagebar son vulnerables a XSS.

Si alguno de ustedes usa el mencionado plugin y se muestra algún mensaje con la siguientes direcciones URL, entonces necesitan modificar ciertas cosas:

code:

http://tublog.com/index.php?"><script>alert(/XSS/)</script><&paged=2
http://tublog.com/index.php/"><script>alert(/XSS/)</script><&paged=2

Para corregir el problema descrito en el plugin pagebar, tienen que escapar el valor devuelto por get_pagenum_link con las funciones attribute_escape o clean_url. Por si alguien desea, puede bajar la versión modificada o aplicar el parche que corrige estos problemas.

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.