Gestores de contraseñas y XSS

En Abusing
Password Managers with XSS
que se refiere a una forma de engañar al
gestor de contraseñas del navegador.

An issue with both in-browser as well as third-party password managers that gets hardly any attention is how these can be abused by XSS. Because many of these password managers automatically fill login forms, an attacker can use JavaScript to read the contents of the form once it has been filled. The lack of attention this topic receives made me curious to see how exploitable it actually would be. For the purpose of testing, I built a simple PHP application with a functional login page aswell as a second page that is vulnerable to XSS (find them here). I then proceded to experiment with different JavaScript, attempting to steal user credentials with XSS from the following password managers:

LastPass (Current version as of April 2012)
Chrome (version 17)
Firefox (version 11)
Internet Explorer (version 9)

I first visited my login page and entered my password. If the password manager asked me if I wanted it to be remembered, I said yes. I then went to the XSS vulnerable page in my application and experimented with different JavaScript, attempting to access the credentials stored by the browser or password manager.

Soy muy partidario de utilizar un gestor de contraseñas, pero no me siento confortable con que esté en el propio navegador porque pueden pasar cosas como estas.

Un bug en SSL relacionado con los enteros

Tengo un poco abandonado este sitio. No por falta de enlaces guardados (aunque sí de lecturas, que últimamente tengo menos) sino por un cierto estado de (des)ánimo. Aprovecho un rato que tengo ahora para escribir una entrada y (tal vez) programar otras.

En este caso es una de esas que me gustan bastante: un fallo sencillo de ver que afecta a un programa (que, además, es un programa supuestamente seguro): incorrect integer conversions in OpenSSL can result in memory corruption.

El problema tendría que ver con un paso de un entero largo a un entero que en algunos casos podría provocar que en una reducción de espacio de memoria (que era algo que no estaba previsto en las bibliotecas correspondientes) provocara un desbordamiento. Un poco técnico, pero que nos muestra como esas pequeñas inconsistencias no previstas pueden provocarnos un dolor de cabeza.

Números aleatorios y seguridad

En Flaw Found in an Online Encryption Method un resumen periodístico de un fallo de seguridad relacionado con la generación de números aleatorios y que utiliza (otra vez) información públcicamente disponible en la red para hacerse una idea del tamaño del problema:

The researchers examined public databases of 7.1 million public keys used to secure e-mail messages, online banking transactions and other secure data exchanges. The researchers employed the Euclidean algorithm, an efficient way to find the greatest common divisor of two integers, to examine those public key numbers. They were able to produce evidence that a small percentage of those numbers were not truly random, making it possible to determine the underlying numbers, or secret keys, used to generate the public key.

La generación de números aleatorios (generación, porque no solemos disponer de fuentes verdaderamente aleatorias para obtenerlos) es un problema crítico en criptografía. Este trabajo nos muestra que no siempre se hace bien.

Hay más información en
Crypto shocker: four of every 1,000 public keys provide no security (updated)

“Our only conclusion is that there is not just one cause for all of these problems,” Hughes said. “This leads to our conclusion that unless you can totally trust your random number generator, RSA is not a good algorithm to choose.”

Y por si acaso alguien quiere acceder a las fuentes primarias, [PDF] Ron Was Wrong, Whit Is Right.

¿Falla el modelado de amenazas?

Se habla bastante del tema de modelado de amenazas pero no hay (o yo no conozco) muchos sitios donde uno pueda aprender a hacerlo bien: los que saben, es porque conocen su contexto y tienen cierta experiencia; los que conocen nuestro contexto, no siempre saben de seguridad.
En Why Threat Modelling fails in practice hablan del tema.

Dice hacia el final:

Threat modelling therefore reveals itself to be theoretically sound but not necessarily helpful. It is then no surprise that SSL performed perfectly against its chosen threats, but did little to offend the risks that users face. Indeed, arguably, as much as it might have stopped some risks, it helped other risks to proceed in natural evolution. Because SSL dealt perfectly with all its chosen threats, it ended up providing a false sense of false security against harm-incurring risks (remember SSL & Firewalls?).

Al final, un tema del que hemos hablado otras veces: lo que parece seguro no siempre lo es; a veces, incluso puede perjudicar la percepción de los que lo usan y hacerles creer que tienen comportamientos razonables y conseguir que se confíen.

Fallos por todas partes

Algo que la gente no cree cuando se lo decimos es que todo el mundo comente fallos (algunos que pueden tener consecuencias verdaderamente graves), hasta los más grandes. Por eso es bueno recopilarlos, para tenerlos a mano cuando hace falta recordarlo. En este caso es Hacking Google for Fun and Profit donde nos cuentan algunos fallos para desvelar información sobre usuarios de gmail: por ejemplo, cómo era posible determinar si un usuario había enviado un mail a otro. Se utilizaban fallos de Cross Site Request Forgery (CSRF), esto es, cuando engañamos al navegador (y al sitio, claro) para que haga una petición en nombre del usuario de la que somos capaces de sacar partido.

Un fallo sutil

Parece que últimamente, además de tener este sitio un poco abandonado, apostamos por historias un poco truculentas y sutiles. Supongo que para temas más del día a día hay otros blogs y a uno le gustan las cosas que le gustan. En I Saw An Extremely Subtle Bug Today And I Just Have To Tell Someone cuentan como encontraron un fallo bastante sutil y cómo descubrieron el origen.

De hecho, en este caso se trata de una condición de carrera que es un fallo difícil de encontrar, sobre todo cuando ni siquiera se está pensando en ello.

Podemos extraer enseñanzas generales: tenemos sistemas muy complejos (combinación de hardware diverso, sobre el que va el sistema operativo, y seguramente varios niveles más de software apildos). Cuando el fallo es obvio, está más o menos claro donde mirar; pero cuando hay interacciones, la cosa se complica.

El tamaño (del código) importa

En Size is the best predictor of code quality un par de enlaces y punteros a estudios sobre el tema (cuando los lea tal vez volvamos sobre ello).
Comenta sobre las métricas de código y su impacto en la robustez y fiabilidad del código y cómo parece que el tamaño sigue siendo un buen predictor.

Creo que habíamos hablado del tema en algún momento, pero no lo encuentro.

SMS y fallos. Ahora en Windows Phone

Lo veo en Descubierta vulnerabilidad a través de mensajes SMS en Windows Phone 7 y apunta a Windows Phone SMS attack discovered, reboots device and disables messaging hub donde cuentan más detalles (pero no muchos). El envío de un mensaje ‘adecuado’ reiniciaría el teléfono y deshabilitaría algunas funciones.

Ya hemos hablado en vidas anteriores de otros problemas con los SMS:

Cuidado con los secretos

Hay gente que cree que es suficiente con ofuscar algo para que otros no puedan acceder a la información (de hecho, creen que sus métodos de ofuscación son realmente métodos de cifrado). En Nuclear sub secrets revealed by mod ‘schoolboy error’ nos cuentan un caso de estos:

But in what was described as “a schoolboy ­error” the technique used by MoD staff to censor the ­document was easy to reverse. The bunglers turned the text background black – making the words unreadable – but crucially left them in place. That meant anyone wanting to read the censored sections just had to copy the text.