¿Qué sitios aún son vulnerables a FireSheep?

Navega tus respuestas
3

Estoy haciendo una demostración de Firesheep en unas pocas semanas como un proyecto de conciencia de seguridad. Sin embargo, parece que no puedo hacerlo funcionar, y me pregunto si es solo porque los manejadores con los que se envía están obsoletos porque todos han arreglado sus sitios.

Voy a continuar con la solución de problemas desde el lado de los conductores promiscuos, etc., pero me preguntaba si:

  1. ¿Alguien podría decirme qué sitios aún son vulnerables a Firesheep?

  2. ¿Alguien podría compartir los scripts del controlador que funcionan en esos sitios? Yo voy a Por supuesto, trate de escribirlos yo mismo, una vez que pueda decir que está funcionando como esperado).

Edit: Gracias por los comentarios. Entiendo lo que hace que un sitio sea vulnerable, pero aún así sería genial tener algunos ejemplos de aquellos que tienen una instalación de Firesheep actualmente en funcionamiento, solo para cierta certeza. ¡Y una muestra de un script de controlador de trabajo conocido sería fantástico!

    
pregunta scuzzy-delta 13.02.2012 - 04:14
fuente

3 respuestas

9

En pocas palabras, cualquier cosa que no use HTTPS para todas las conexiones es vulnerable a Firesheep.

Puedo imaginar que muchos de los scripts de controladores originales ya no funcionan porque una gran cantidad de sitios han arreglado sus sitios para usar HTTPS. O si eran realmente perezosos, solo modificaban las cosas ligeramente para oscurecer las cosas.

Probé Firesheep cuando se lanzó y no pude escuchar el tráfico público con la tarjeta wifi incorporada de mi computadora portátil. Si ese es el problema que tiene, probablemente sea porque no es compatible con el modo de monitoreo. Un dongle wifi usb 10-20 $ resolverá ese problema.  Tengo un ASUS USB-N13 que soporta el modo de monitoreo. Creo que va por 20 $ más o menos ahora.

Como menciona Rook, toda la red de sitios de Stack Exchange es vulnerable. De hecho, la última vez que revisé los creadores de Stack Exchange ni siquiera pienses que es importante . O al menos no era lo suficientemente importante para la dificultad involucrada.

Firesheep está diseñado para mostrar la inseguridad conocida de no usar HTTPS. Funcionó bien ya que muchos sitios web comenzaron a usar HTTPS justo después de su lanzamiento.

Hay otro uso para Firesheep que es un poco menos conocido. También se puede utilizar en redes WPA2-AES cifradas para mostrar la vulnerabilidad "Hole196" en WPA2. No creo que la versión original de Firesheep incluya esta funcionalidad, pero existen versiones modificadas que sí lo hacen. El creador de Firesheep pensó que incluir la característica WPA2 era demasiado peligroso, y estoy de acuerdo. (cita requerida)

    
respondido por el WalterJ89 13.02.2012 - 05:33
fuente
3

Como torre, los sitios web de stackexchange no utilizan cookies seguras (solo para HTTPS) o HTTPS en ningún lugar de sus sitios (aparte de la autenticación a través de un tercero).

Eso significa que cuando inicias sesión en stackexchange, un intruso (que utiliza firesheep, wireshark o similar) puede robar las cookies para indicar que has iniciado sesión en stackexchange. Luego, pueden usar estas cookies durante meses para acceder a su cuenta como usted.

Ahora es posible que también puedan capturar su contraseña real que está vinculada a su nombre de usuario si escuchan al iniciar sesión, según el mecanismo que utilice. Es decir, si inicia sesión a través de google / yahoo / myopenid / facebook, sus credenciales de inicio de sesión estarán protegidas para los intrusos que capturan paquetes a través de la red.

Sin embargo,

(!), si inicia sesión con una stackexchange account no hay https (incluso en el acción posterior del formulario), por lo que su nombre de usuario / contraseña se envía a stackexchange en texto sin formato a cualquier persona que se moleste en escuchar.

    
respondido por el dr jimbob 16.02.2012 - 23:03
fuente
0

Hay dos tipos de sitios que son vulnerables:

  1. Sitios que utilizan HTTP en cualquier parte del sitio. Algunos sitios solo admiten HTTP y no admiten HTTPS (por ejemplo, StackExchange); son vulnerables Algunos sitios utilizan una combinación de HTTP y HTTPS (por ejemplo, Amazon); ellos también suelen ser vulnerables.

  2. Sitios que usan cookies que no tienen el indicador de seguridad establecido. Las cookies con la marca de seguridad solo se enviarán a través de HTTPS. Las cookies sin el indicador de seguridad se devolverán al sitio a través de cualquier conexión, incluidas HTTP y HTTPS. (Si un sitio configura una cookie no segura a través de una conexión HTTPS, aún se enviará a través de conexiones HTTP). Por lo tanto, si el sitio configura cookies no seguras, un atacante activo puede activar su navegador para conectarse al sitio a través de HTTP y luego robar la cookie. Esto se aplica incluso si el sitio utiliza HTTPS en todo el sitio.

Para defenderse de los ataques tipo Firesheep, los sitios deben hacer dos cosas:

  1. Deben usar HTTPS en todo el sitio. (No use HTTP para nada.)

  2. Deben establecer la marca de seguridad en todas las cookies.

Necesitan hacer ambas cosas: solo una no es suficiente.

    
respondido por el D.W. 19.02.2012 - 08:27
fuente

Lea otras preguntas en las etiquetas

Binarios o archivos del programa con el mismo hash MD5 ¿De qué nos protege una red conmutada? ¿De qué no nos protege?