Estas aquiContenido / Vulnerabilidad en Gmail
Vulnerabilidad en Gmail
Ni es la primera de este tipo ni tampoco me atrevo a llamarla nueva, porque al parecer Google fue informado en Agosto de 2007 de esta vulnerabilidad, que no ha solucionado porque le parece difícilmente explotable.
El descubridor es un español (Vicente Aguilera, de ISecAuditors) que ha decidido publicar hoy una descripción y prueba de concepto.
Se trata de una vulnerabilidad del tipo CSRF, que permitiría a un atacante cambiar la contraseña de un usuario de Gmail sin su conocimiento.
- 30 lecturas
Etiquetas
Demasiado grave. Sobre todo si intentan vender su servicio a corporaciones; de qué sirven sus alegatos de que su servicio es muy estable (que lo es, aunque hace poco cayera) si existe una forma tan fácil de robar las cuentas. Que imaginen qué pasaría si le robaran la cuenta Sergey Brin y Larry Page a ver si así lo toman como algo más serio...
Hay cosas que decepcionan en esto de la informática…
Por lo que contais aquí, creo que es posible que se esté produciendo un robo de cuentas de correo en la provincia de Cádiz y alrededores. Ya se que los correos no tienen nada que ver con una localización geográfica, pero se esta utilizando para una venganza, o al menos es lo que parece de una persona residente en Jerez de la Frontera o en Huelva.
En mi blog tengo algo más de información.
Posible robo de cuentas en Gmail
Lo peor es que leyendo el enlace, en google saben del tema desde julio del 2007, y han pasado del problema como de ingerir catalinas (vulgo comer mierd.. eso).
Se podría decir que la actitud de SG es cuando menos próxima a la prepotencia... Por si acaso, mejor no cambiar las contraseñas de google salvo emergencias.
Quizá soy un poco inocente, pero creía que Bugtraq sí estaría interesado en informar de algo así; y, de no hacerlo, daría motivos...
Es posible que la falta de solución, y su enorme impacto, les impulse a no publicarlo?
El tema de Bugtraq daría para un culebrón.
Bugtraq fue originalmente una lista sin moderación, al estilo de lo que es full-disclosure en la actualidad, nacida dentro del movimiento que abogaba por la publicación libre de vulnerabilidades, la finalización de las políticas non-disclosure, la transparencia del "mercado de la seguridad", etc.
A los pocos años de su creación y debido a la cantidad de basura que se publicaba, igual que en la lista full-disclosure actualmente, se decidió por un estilo moderado.
Paradójicamente, con este cambio llegó "la época dorada de Bugtraq", desde 1996 hasta 2001. En esta época el moderador de Bugtraq, fue Elias Levy (aka. Aleph One) y se caracterizó por tener unos criterios bastante estrictos para la publicación de contenidos y un control bastante férreo de la calidad de lo que se publicaba. Eso sí, un post denegado siempre solía ir acompañado de una explicación del motivo, y de recomendaciones, desde "esto no es una vulnerabilidad explotable, coméntalo mejor en vuln-dev" a "escríbeme el advisory en inglés, por favor". Todo ello, hizo que la lista adquiriese un prestigio internacional y fuese considerada como toda una referencia en su sector.
Sin embargo, en el año 2002 Bugtraq (que en ese momento y desde el 99 se encontraba gestionada por SecurityFocus, la empresa de Elias Levy) empezó a ser gestionada por Symantec como parte de la adquisición de SecurityFocus. Esto supuso la salida de Aleph One de la moderación y un sustancial cambio.
Desde el 2003 al 2006 pusieron un "hombre de paja", Amhad, que no fue excesivamente aplaudido, principalmente por inexperiencia y por "una falta de profesionalidad" respecto a lo que había sido la moderación de Elias Levy. En esta época los post se retrasaban sin motivo, no eran publicados (y no se recibían recomendaciones, ni motivos), etc, etc.
A partir de 2006, Bugtraq es gestionada por un hombre "de la casa" (es decir, por un trabajador a cuenta de Symantec). Su calidad en la moderación se situa en un punto intermedio, por decirlo de alguna forma ... no son los tiempos de Aleph One, pero en mi modesta opinión lo hace mejor que Amhad.
Eso sí, desde el año 2002, Bugtraq no es una fuente independiente de información, puesto que forma parte de una corporación que vende seguridad de la información, y se ajusta a sus criterios. Entre sus prácticas (no publicadas) se incluyen: el rechazo y no publicación (sin motivo) de cualquier envío realizado, el "tratamiento" selectivo de la información recibida, el reparto información preferente entre sus "clientes", etc.
Como respuesta a estas actitudes, y coincidiendo con el inicio del control de Symantec sobre SecurityFocus, se creó full-disclosure. Y aunque no voy a decir eso de que "ha sido peor el remedio que la enfermedad", puesto que no soy de esa opinión. Sí que diré que Full-Disclosure dista mucho de ser una fuente de información fiable en materia de seguridad de la información, aunque desde luego ... es "una gran fuente" donde hay de todo.
Saludos.
Vamos, una vez más, a intentar esclarecer al máximo la "supuesta vulnerabilidad", que como el mismo autor comenta ha sido "rechazada 2 veces" para su publicación en Bugtraq y ha tenido que ser publicada en una lista sin moderación (full-disclosure).
1º ¿Existe un XSRF en Gmail?
No. Un XSRF sólamente existe cuando no hay ningún mecanismo de verificación que permita determinar que una acción concreta ha sido realizada por el usuario legítimo.
En este caso concreto, y como se ven el vector de ataque:
Es necesario conocer (o adivinar) el password de la cuenta para que el ataque sea posible.
Por tanto, existe un mecanismo de control que verifica que la acción ha sido desempeñada por un usuario legítimo: su password.
2º ¿Es el mejor mecanismo para evitar XSRF y controlar la sesión?
No. El mecanismo ideal para evitar XSRF sería un ID aleatorio de un sólo uso y 16 bytes de longitud, activado cuando el usuario legítimo invoque la acción EditPasswd y verificado por la acción UpdatePasswd.
3º ¿Esto constituye una vulnerabilidad?
De tipo XSRF no. Es una vulnerabilidad que como mucho, podrá ser catalogada de "debilidad menor en el control de sesión" y su impacto desde luego es muy bajo (cuando no informativo).
4º ¿Esto debe preocupar al usuario de GMAIL?
No. La longitud mínima de una contraseña de GMAIL es de 8 caracteres. Y aunque insisto no es el mejor sistema, la posibilidad de modificar la contraseña en este tipo de ataque es de 1 sobre 281474976710656.
Paralelamente, el vector de ataque permitiría en caso de éxito, modificar la contraseña de un usuario .. pero sin conocer de qué usuario ha sido modificada.
5º Conclusión
Esta "vulnerabilidad" de impacto muy bajo, únicamente permite un ataque en función de la robustez de la contraseña (1 sobre 281474976710656 de acertar en cada ataque).
Además de ello, al ser un ataque pasivo, el usuario debe visitar una web maliciosa que lo realice.
La única "ventaja" de este ataque sobre probar al azar usuarios y contraseñas, es que no es necesario conocer el usuario para realizar el crackeo.
Por otra parte ... y debido a que no se conoce el usuario sobre el que en caso de éxito se ha modificado la contraseña (ya que no forma parte del vector de ataque ..) su utilidad es nula en un escenario real.
Amen.
XD
Tengo alguna duda sobre la inutilidad de la vulnerabilidad:
1.- El hecho de que no se pueda conocer la cuenta abierta en otra pestaña del navegador desde la que se accede a un link no lo tengo tan seguro
Yo he comprobado en algunas páginas que me sucede lo siguiente:
-Firefox 3.0.3
-Noscript instalado
-En una pestaña logado en gmail
-En otra pestaña abrir http://ferhergon.blogspot.com/ y click en los comentarios de algunos de los artículos. (blogger.com y blogspot.com bloqueados por noscript)
-Detecta mi nombre de usuario en gmail!
No tengo muy claro por que sucede esto pero es real y comprobable.
2.- ¿Podría realizarse la siguiente modificación del ataque?
Si el usuario en vez de hacer click en un enlace este click lanzará un javascript que lanzará el mismo ataque basado en un diccionario podría tener bastantes más probabilidades de dar con la adecuada.
A lo que iba, ¿esto que digo es una tontería?
Gracias
No creo que digas "ninguna tontería".
A la primera pregunta: ¿Es posible determinar el usuario que está siendo víctima del ataque? Con esa sóla vulnerabilidad no.
No obstante, debido a que Google tiene una infraestructura SSO (Single Sign-On) una vulnerabilidad en otro servicio, podría escalar hacia detectar la cuenta
... el caso de blogspot y blogger, debido a que son servicios de Google
... son capaces de detectar la cuenta. No obstante y en un principio (habría que auditarlo con ganas) en blogspot (donde un supuesto usuario malicioso inserte JS) no va a recibir esas credenciales ... puesto que van contra google/blogger y es blogger internamente el que las recoge (en un principio para evitar que un XSS en fulanito.blogspot.com permita robar credenciales).
Habría que echarle un "rato". Pero vamos .. sin marear tanto la "perdiz" existe un ataque más$ sencillo, basado en ingeniería social. "Sorteo de un chipiklander" --> inserta tu dirección de correo --> si es de gmail --> bruteforcing al canto.
Es decir, cuando digo que el ataque "por si sólo no sabe sobre qué cuenta está actuando", no niego inherentemente que complicandolo un poco (o tirando de rostro puro y duro) no se pueda sacar un user sobre el que bruteforcear.
A la segunda pregunta: Puedes hacer JS .. como puedes hacer insertar 1 millón de imágenes. El hecho es el mismo ... el JS tiene que hacer "1 millón" (son bastantes más) de peticiones.
El hecho, es que ahora mismo el password de un usuario de gmail (de una cuenta actual, que si no me gruñen) debe ser 8 caracteres alfanumérico.
8 caracteres alphanum dan un espacio de búsqueda "muy grande", para hacer un ataque "no persistente" sobre un navegador.
Es decir, al fin y al cabo este ataque va a durar "lo que el tío que ve la página se canse y la cierre" (o cierre el navegador completo, por si hay "técnicas de ocultación").
En definitiva .. que se le pueden dar muchas vueltas pero que esto no es un XSRF ... esto todo lo más, vuelvo a insistir es "una debilidad menor en el proceso de control de sesión".
Y si nos ponemos a "lo peor" puede tener una incidencia sobre cuentas con password del tipo "123456" "abcdef", que evidentemente pueden existir en cuentas antiguas ... y que combinado con ingeniería social y "suerte" pueden permitir en un extremo robar una cuenta de gmail.
Pero vamos ... que esto no es un XSRF y que la cuenta de un usuario con una password de una complejidad razonable, en ningún momento está "en peligro". Casos extremos de passwords triviales, puede ser ... pero vamos, ese tipo de cuentas está en peligro siempre, exista este mecanismo o no.
Hola,
Solo una pregunta, afecta también a los que utilizamos el gmail con https ??
Gracias.