HACKING TUENTY...POSIBLE MAN IN THE MIDDLE..y tocando los webs!!!

Buenos Días curiosos, hoy, jueves , junio 02, 2011, HACKEAMOS A TUENTI..BY JUAN CARLOS GARCÍA..VEAMOS QUE ES TUENTY AND HOW TO HACK TUENTY...?...Tocando los webs de nuevo..Fallos apreciados ! ! !

Tuenti Security

Tuenti es una red social que tiene el honor de ser una de las startups tecnológicas españolas que más éxito están teniendo. A día de hoy cuenta con una cuota de uso entre jóvenes altísima, y es la más popular aquí en España, con diferencia, en rangos de edad de menores de 30 años – como no es mi caso, primero porque tengo 35, y los perfiles, pienso, que es para más jugueteo, de ahí que sea mi plataforma preferida para hackearla.Facebook, quieras o no, fue la primera, y os aseguro que tanto el inicio de la idea, el hacking necesario de Harvard Server para la obtención de información de cuentas de email para comenzar haciendo lo que hoy se llama como "likejacking"....

Sin embargo, como dijo el tío Ben, todo gran poder conlleva una gran responsabilidad, por lo que debido a que son el punto de acceso principal de los jóvenes españoles, deben tener especial cuidado contra los depredadores y atacantes...lo bueno de esto, es que, mientras a nadie le importe una mierda la seguridad, y más en los perfiles tuenti, son objetos mío y de miles de compis que conozco, donde probamos técnicas de hacking en redes sociales, y que me sirve para poner mis conclusiones aquí....

Sé de buena tinta que se toman los bugs de seguridad bastante en serio, tras la experiencia que tuvimos con un bug de XSS que permitía hacer Hijacking, aunque también tienen cosas que pueden ser mejoradas, por eso me decidí a pedir contribuciones por twitter de fallos y debilidades en el sistema de Tuenti que ellos conozcan porque ya se los hayan notificado, y que deban ser mejorados.

Me consta que muchas de estos issues están en el roadmap de Tuenti y que los tienen en el ToDo para dejar una plataforma más segura. Sin embargo, a día de hoy todavía están aquí. Vamos con la primera parte del artículo con lo que a primera vista cualquiera puede notar.

Issue 1: La página de login bajo HTTP

Una de las cosas que deben ser tenidas en cuenta es que hay que evitar los puentes HTTP-HTTP-s en las páginas donde un usuario debe introducir sus credenciales de acceso. Hay que tener en cuenta que un atacante podría realizar una ataque Man in the Middle para hacer un ataque SSLStrip, es decir, en el que se quitan todos los links HTTP-s entre la víctima y el atacante y robar las credenciales.



Figura 1: Puente http/http-s en el formulario de login

Al estar entregado el formulario bajo HTTP, la victima jamás recibiría una alerta de seguridad si hay un mitm con sslstrip. Es por eso que es necesario que las credenciales se introduzcan bajo formularios entregados con HTTP-s y que no mezcle contenido mixto HTTP y HTTP-s en la misma página.

Issue 2: La página de login bajo HTTP… quieras o no

En muchas aplicaciones web, la página de login se entrega por defecto bajo HTTP, pero los usuarios más avanzados y preocupados por la seguridad, solicitan el acceso bajo HTTP-s forzando manualmente la URL o utilizando extensiones de los navegadores que eviten las redirecciones a HTTP. Sin embargo, con Tuenti es imposible, porque si se solicita la página bajo HTTP-s siempre obliga a autenticarse bajo HTTP.




Olvidate por tanto, de utilizar extensiones para forzar el uso de HTTP-s en las conexiones con HTTPS Everywhere, Force-TLS o KB SSL Enforcer.

Issue 3: Certificado digital sin validación extendida

Los certificados digitales que compran las organizaciones pueden obtenerse con procesos automáticos o mediante la validación extendida de personas. La validación extendida ayuda a garantizar a un usuario que el certificado no ha sido obtenido mediante un proceso automático que, como demostró Moxie Marlinspike, con el bug del null byte, pueden ser susceptibles de fallar.

Issue 4: Certificado digital con cifrados débiles

A la hora de generar un certificado digital, se pueden elegir los algoritmos que se van a permitir en los túneles SSL. En este caso, los algoritmos que permite son algunos inseguros y deberían deshabilitarse para evitar ataques de crackeo offline de las conexiones, además de establecerse una prioridad de uso.

-Y atención_.... TLS-Renegotiation gap, SSL Resumption y PCI-Compliant

Cuando se realiza el análisis de Qualys para certificados digitales, llama la atención la baja nota que se obtiene con este tipo de certificados y, especialmente, en la parte de negociación de claves. Esto es así porque han anulado la Renegociación TLS para evitar el bug de TLS-Renogation en lugar de parchearlo, está anulado, que es un workaround bastante criticado porque deja en manos del cliente definir el nivel de seguridad del servidor manualmente.



Calficación obtenida en el test Qualys

En segundo lugar, aparece una nota negativa porque el certificado no está hacieno uso de los IDS para reutilizar datos de sesiones exitosas, lo que haría que el rendimeinto de las conexiones fuera mucho más alto.


Así, mirando las características en total del certificado, como se puede ver, no pasaría una auditoría PCI, aunque hay que decir que Tuenti no está obligado a pasarla.

Estos 5 Issues no son bugs de seguridad en Tuenti, sino puntos que deben mejorarse para aplicar los principios de Mínimo Punto Exposición, Mínimo Privilegio Posible y Defensa en Profundidad, fundamentales en los procesos de Hardening de Sistemas.

by the Face By Duke ! !
********************
********************
*******
***
**
*

Entradas populares de este blog

Proteger ASP.NET de inyecciones SQL How T0? BEST PRACTICES

CERTIFICACIONES DE SEGURIDAD

HACKING MADRID_"EASY" XSS and Cross Site Tracing XST