Cuidadín con el "Linkedín" en las conferencias de "hackín"

Linkedin es una de esas redes sociales supuestamente creadas para no ligar. Sí, y sorprendentemente funciona, pero lo cierto es que su éxito se debe a que la gente también la usa para ligar. Por eso yo también tengo Linkedin. Así es la vida.

Ayer, en Naked Security se quejaban de que la opción por defecto de permitir ver el correo electrónico de los participantes en un mensaje debería tener el otro valor por omisión. Es decir, que debería venir desmarcado el check box para que no dependiera del usuario, que se podía descuidar como deja bien claro que le sucedió a su compañero Pablo, que tiene su base en Madrid - ¡Pablo, estamos contigo! -.

El caso es que Linkedin me tenía bastante rayado tiempo ha, porque la página web de login era vulnerable a SSLSTrip y la sesión iba en HTTP, y, sin embago, en las conferencias de seguridad y hacking, mientras tiene lugar el evento, siempre me llegan invitaciones de asistentes o ponentes a la misma.

El tema del SSLStrip

Realmente, si nos ponemos finos, todas las webs pueden ser vulnerables a SSLStrip, ya que realmente es un ataque Man in The Middle que se realiza por la red para quitar los enlaces https. Cuando yo me refiero a que una web es vulnerable a SSLStrip es porque tiene el problema de los puentes, es decir, que el usuario teclea su login y password en un formulario servido por HTTP esperando que cuando se haga clic en el botón de login aparezca, al más puro estilo de Indiana Jones y la Última Cruzada, el puente salvador que permita llegar a por el Grial.


Figura 1: Login SSLStripeado
Esto ha sido así hasta hace nada, ya que acaban de poner el login seguro. No puedo deciros exáctamente cuando hicieron el cambio, pero en la Troopers 2011 Steve Dispensa y yo estuvimos charlando sobre este caso y analizándolo para su demo de Phone Factor, y ayer, el login seguro llevaba menos de 24 horas.


Figura 2: Login Seguro en Google
Sin embargo, todavía es posible encontrar logins en Linkedin sin usar Https en el formulario de introducción de passwords, como este para los developers.


Figura 3: Developers login en Linkedin
Además, cuando se recibe una invitación para estar conectado y se acepta o se visita el perfil, el login que propone linkedin es también con un formulario visualizado bajo Http en http://www.linkedin.com/mbox


Figura 4: formulario de acceso a linkedin bajo http
El tema del Firesheep

Lo que sigue estando presente es que, una vez conectado, la sesión va en Http, así que decidimos hacer un pequeño script para que rulara el Firesheep, y nuestro amigo madridista "Culé hasta la médula" Daniel Romero, entre auditoría y auditoría, se puso con el Burp a usar el repeater para descubrir cuál es la cookie que permite mantener la sesión abierta. Y helo aquí.


Figura 5: Linkedin Firesheepeado
// Author: Informática64 - www.informatica64.com
register({
name: "Linkedin",
url: 'http://www.linkedin.com/',
domains: [ 'linkedin.com' ],
sessionCookieNames: [ 'leo_auth_token' ],
identifyUser: function () {
var resp = this.httpGet(this.siteUrl);
this.userName = 'LinkEdin User';
this.userAvatar = 'http://bitelia.com/files/2010/09/linkedin-logo.jpg';
}
});

Además, adoleciendo del problema que tienen muchos servicios en Internet que funcionan con arquitecturas cluster o en la nube, la muerte de la cookie dura mucho más allá del cierre de la sesión, con lo que es posible seguir controlando el perfil.

Uvepeeneate

La solución pasa por no usar Linkedin en una conferencia de hackers si no es a través de una VPN segura - nada de conexioens VPN vulnerables a man in the middle y cracking -, que como se ponga de moda el tener perfíles de hackers o gente de seguridad que tiene su perfíl en Linkedin esto puede ser una escabechina.

Saludos Malignos!