Category: XSS

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.

Categories
Seguridad Web WordPress XSS

Más vulnerabilidades XSS en WordPress

La primera de ellas afecta a la función wp_title(), en el que el parámetro year no es filtrado adecuadamente, para esta vulnerabilidad ya existe un parche disponible en la versión de desarrollo.

code:

http://vulnerable/?year=</title><script>alert("XSS")</script>

Sobre el segundo fallo, reportado hace algunas horas por otra persona -pero sobre el cuál tenía conocimiento e inclusive había preparado un pequeño exploit la semana anterior 🙂 , es bastante más peligroso dependiendo de las condiciones en que se desarrollaría el ataque. Al igual que menéame hace algún tiempo, wordpress es vulnerable por el mal uso de la variable $_SERVER['PHP_SELF'].

Para reproducir este bug en la página principal, en general depende de la estructura de URL's que hayan definido para vuestras entradas, pero este problema también se puede reproducir en el panel de administración, donde puede tener consecuencias mucho más peligrosas (como la ejecución remota de código PHP).

Por obvias razones, todavía no mostraré el exploit, pero si quieren quieren una solución temporal, pueden incluir el siguiente código después de la línea 49 en wp-settings.php.

php:

$PHP_SELF = $_SERVER['PHP_SELF'] = htmlspecialchars(strip_tags($_SERVER['PHP_SELF']), ENT_QUOTES);

Cuando salga la corrección oficial para el segundo bug, mostraré el código vulnerable y todos los detalles del exploit 😉

Categories
Desarrollo de Software Seguridad Software Libre Web WordPress XSS

Múltiples vulnerabilidades XSS en WordPress y el plugin Akismet

Actualización (09/03/2007): Finalmente ya existe un parche oficial para el problema reportado el lunes pasado (Secunia Advisory SA24430, Ticket WordPress), como había comentado estos fallos afectaban a la rama 2.x y a la última versión de desarrollo, adicionalmente se han hecho correcciones en otros archivos más:

  • Rama 2.0
    • wp-admin/admin-functions.php (equivale al problema reportado en wp-admin/import/mt.php)
  • Rama 2.1
    • wp-admin/admin-functions.php
    • wp-admin/custom-header.php
    • wp-admin/upload-functions.php (no reportado previamente)
    • wp-includes/script-loader.php (no reportado previamente)
  • Versión en desarrollo
    • wp-admin/admin-functions.php
    • wp-admin/custom-header.php
    • wp-admin/upload-functions.php (no reportado previamente)
    • wp-includes/script-loader.php (no reportado previamente)

El fallo todavía persiste en el plugin akismet, hasta que lo solucionen pueden usar la versión modificada que puse hace unos días.

Desde los casi tres años que vengo usando WordPress, es la primera vez que veo que se reportan con mayor frecuencia fallos de seguridad en este CMS, imagino que esto se debe a la popularidad que alcanzó y también a nuevas características que se añaden en cada versión mayor.

Por otro lado, uno de los aspectos que hace de WordPress una aplicación muy extensible y a la vez bastante insegura son los plugins, puesto que los que alguna vez desarrollamos uno de éstos, probablemente hayamos introducido algún fallo de tipo SQL Injection, XSS o el menos tomado en cuenta CSRF, que entre otras cosas van a comprometer la instalación principal de WordPress e inclusive el servidor donde se aloja éste.

Me parece que alguien debería evangelizar la escritura de plugins seguros por el daño que pueden causar sin son mal programados -de nada sirve que los desarrolladores de este CMS se "rompan el lomo" añadiendo características para hacer más seguro el core, si en los plugins casi nadie más las usa por desconocimiento o falta de documentación.

En fin, hago el comentario anterior, puesto gran parte de los plugins que actualmente estoy usando, tienen problemas de seguridad* (XSS y CSRF principalmente), que en la medida de lo posible, intentaré reportarlo a sus autores.

Luego de la larga y aburrida queja, paso a comentar que existen vulnerabilidades de tipo XSS en los siguientes archivos.

  1. wp-admin/edit-comments.php: no se escapan parámetros arbitrarios al momento de realizar la paginación. Prueba de concepto.
  2. wp-admin/import/mt.php: no se escapa la url que se genera para el atributo action del formulario para importar un blog del tipo Movable Type. Prueba de concepto.
  3. wp-admin/custom-header.php: el mismo problema de validación de datos, no pongo una prueba de concepto porque no se puede acceder directamente a esta página.
  4. wp-content/plugins/akismet/akismet.php: el mismo problema del punto 1 al momento de paginar los comentarios de tipo spam, la prueba de concepto es parecida, sólo hay que agregar el parámetro page=akismet-admin.

Al momento de publicar esta entrada programada, seguramente ya habrá un parche oficial en la página de reporte de incidencias de WordPress (aunque hice el reporte a través de security@wordpress.org), pero para los impacientes pongo una solución temporal (**).

Actualización (06/03/2007): Los fallos en wp-admin/edit-comments.php y wp-admin/custom-header.php sólo se pueden reproducir a partir de la rama 2.1.x, el de wp-admin/import/mt.php y akismet me parece que a partir de la rama 2.0.x.

*: Si, también los plugins que desarrollé tienen estos problemas 😀 , pero estoy aprendiendo.
**: Los archivos modificados corresponden a la versión 2.1.2 (ver diferencias), úsenlo bajo vuestra responsabilidad.

Categories
CSRF Seguridad Sql Injection Web XSS

Sistemas de estadísticas Web y datos sobre las búsquedas

Your Traffic stats
Frecuencia con que reviso las estadísticas de acceso a este blog 😀 (Fuente isopixel)

Debido a que estos últimos meses en estuve comentando algunos temas relacionados sobre seguridad, ahora recibo unas cuantas visitas de gente buscando información sobre XSS, Sql Injection, CSRF, etc; entre estas visitas también hay algunos que buscan algunos exploits que siguen unos patrones determinados.

Al igual que un caso anterior, esta vez mientras revisaba las estadísticas de acceso al blog en Reinvigorate, un pequeño mensaje salió a la vista:

XSS Message

Al mirar más detenidamente la fuente de ese mensaje, ví que alguien al parecer estaba buscando(*) erróneamente servidores vulnerables o más información sobre un bug reportado por Stefan Esser en el Mes de los Bugs de PHP.

Es interesante como este tipo de búsquedas pueden ayudar a encontrar bugs de manera imprevista 🙂 .

(*) El texto que buscaban era http://www.google.com.ar/search?q=?a[]=<script>alert(/XSS/);</script>

Categories
PHP Seguridad Sql Injection XSS

Filtros genéricos y la seguridad

Hace algún tiempo ya había comentado que este tipo de funciones en general son de poca utilidad y dan una falsa sensación de seguridad a los que las usan.

php:

function antiinjection($str) {
        $banwords = array ("'", ",", ";", "--", " or ", ")", "(", " OR ", " and ", " AND ","\n","\r");
        if ( eregi ( "[a-zA-Z0-9]+", $str ) ) {
                $str = str_replace ( $banwords, '', ( $str ) );
        } else {
                $str = NULL;
        }
        $str = trim($str);
        $str = strip_tags($str);
        $str = stripslashes($str);
        $str = addslashes($str);
        $str = htmlspecialchars($str);
        return $str;
}

¿Qué problemas le encuentran al código mostrado?