************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
Issue 6: Registros PTR publicados en los servidores DNS
Dentro de los servidores DNS de Tuenti se puede ver que Primary Master es dns01.tuenti.com, uno de los servidores publicados en Internet, así que era muy probable que tuviera concentrada en él toda la información de los registros PTR. Haciendo uso de FOCA es bastante sencillo descubrir la infraestructura interna de servidores y máquinas que utiliza todo Tuenti con un PTR Scanning.
Figura 5: Infraestructura de servidores en Tuenti
El exponer la lista de cientos de servidores abre mucho más el abanico a un potencial atacante que quiera probar la seguridad, uno a uno, de todos ellos, complicando mucho más la vida de los equipos de seguridad.
Además esta lista de equipos de red se puede complementar con Shodan, ya que tienen indexados bastantes de los equipos de Tuenti en cada rango, y basta con utilizar el comando NET aplicado a los segmentos descubiertos, para tener una visión bastante completa de toda la red.
Issue 7: Servidores sin actualizar
La parte negativa de que se puedan descubrir muchos servidores con los registros PTR es que permite encontrar servidores perdidos, olvidados, o fuera de la política principal de seguridad porque son de pruebas, temporales, o, incluso, que son dispositivos IP. Mirando alguno al azar, era posible descubrir servidores Apache publicados en servidores accesible por Internet, en los que se muestran las versiones de los productos y, algunos, como en este caso, con vulnerabilidades conocidas, como esta de D.O.S. de fácil explotación con el CVE-2010-1452.
Figura 6: Servidor Sanson.tuenti.com con vulnerabilidades conocidas
Es suficiente con revisar el ChangeLog completo de Apache para ver todos los CVE que le afectan a la versión que estaba publicada.
Issue 8: Los metadatos
No podría dejar de mirar los servidores de Tuenti con la FOCA sin poner un ojo en la recomendación del Esquema Nacional de Seguridad sobre los Metadatos, para ver si estaban haciendo uso de alguna política de limpieza de documentos antes de publicarlos.
Figura 7: Metadatos en documentos publicados en Tuenti
Basta con buscar algunos de los documentos en PDF publicados en Internet, y descubrir nombres de usuarios, versiones del software que han comprado para utilizar en la organización, y quién lo usa, etcétera.
Issue 9: La transferencia de datos del perfil sin HTTPs
Una de las cosas que más problemas genera es la no posibilidad ni por defecto, ni configurándolo, de utilizar conexiones HTTP-s entre el usuario y los servidores de tuenti. Esto hace que cualquier cosa que se transmita pueda ser escuchada y capturada en una red insegura. Quiero centrarme en el término de red insegura, porque a veces los responsables de infraestructuras lo utilizan para pasar responsabilidades de la compañía al usuario – no he dicho que sea el caso de Tuenti -.
Una red insegura es aquella que no ofrece garantías a sus usuarios sobre la seguridad de sus comunicaciones porque no hay garantía que un atacante pueda capturar los datos o manipularlos.
Así, bajo esta definición de redes seguras nos quedarían un puñadito nada más, en las que, por ejemplo entrarían las redes TCP/IP que usan IPSec (con certificados digitales o Kerberos, no con PSK), las redes WiFi que no usan WPA/WPA2-Enterprise con EAP, las redes WIFI con WPA/WP2 con una contraseña no crackeable [WPA/WPA2 Craking] - ya que pueden ser atacadas con man in the middle [Atacar WPA/WPA2 PSK] - y las que se hacen con redes PPTP con SSTP, PPTP con passwords no crackeables y con L2TP/IPSec. El resto serían inseguras.
Eso sí, ésta red “segura” lo sería solo hasta el operador, ya que después no hay garantía ni control más allá de la red, y sucedería lo mismo con la conexión del servidor VPN a los servidors de Tuenti. Además tendríamos que quitar de la lista las conexiones VPN con L2TP/IPsec y PPTP en aquellas redes como hoteles, universidades, etcétera, donde los puertos de conexión estén bloqueados. Las 3G y GPRS deberíamos dejarlas también fuera por los problemas con GSM con A5/0 y A5/1, y por supuesto las redes WPA/WPA2-PSK en las que seamos más de 1 usuario, ya que se podrían hacer ataques de Mitm.
Figura 8: Gráfico de conexiones "seguras"
En este ejemplo, asumiento Internet como red Insegura, los datos del usuario pasarán siempre en abierto, una vez salga de la "red segura" del usuario o de la "red segura del servidor VPN" que usa el usuario.
Tras esta reducción de redes seguras nos queda:
a) Aceptar que el sistema no ofrece privacidad alguna, como en los correos SMTP/POP3, y eso debería dejarse claro cuando se solicitan datos de caracter personal o mensajes privados de los usuarios.
b) Asumir que el servidor se ha diseñado solo para unos pocos afortunados que tienen suerte de que ningún ataque a un Router mueva tráfico a China o algún insider de un operador tenga una tarde graciosa y publique en pastebin los datos de las sesiones de tuenti que pasen por su red.
c) Poner HTTPS con certificados de validación extendida y protocolos de cifrado robustos para extender la seguridad de la red hasta el usuario.
Es por eso, que lo más fácil para mejorara la seguridad es montar HTTP-s y que justificarlo con un “no te conectes desde una red insegura” es una falacia. Evidente, la falta de Http-s en la transferencia de datos no solo afecta a la privacidad de la información intercambiada, como fotos, mensajes, chats, comentarios en muros, etcétera, sino a los datos de la sesión del usuario, lo que hace que sea fácil perpetrar ataques a la cuenta del mismo.
El usuario debe por tanto tener extremado cuidado con la red que utiliza para conectarse, si valora su privacidad y qué datos envía. Este problema, lo han tenido la mayoría, si no todas, de las redes sociales, aunque muchas ya han optado y están optando por poner HTTP-s opcional, cuando menos, para los usuarios más preocupados, y Tuenti lo pondrá no tardando mucho, seguro.
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
Issue 6: Registros PTR publicados en los servidores DNS
Dentro de los servidores DNS de Tuenti se puede ver que Primary Master es dns01.tuenti.com, uno de los servidores publicados en Internet, así que era muy probable que tuviera concentrada en él toda la información de los registros PTR. Haciendo uso de FOCA es bastante sencillo descubrir la infraestructura interna de servidores y máquinas que utiliza todo Tuenti con un PTR Scanning.
Figura 5: Infraestructura de servidores en Tuenti
El exponer la lista de cientos de servidores abre mucho más el abanico a un potencial atacante que quiera probar la seguridad, uno a uno, de todos ellos, complicando mucho más la vida de los equipos de seguridad.
Además esta lista de equipos de red se puede complementar con Shodan, ya que tienen indexados bastantes de los equipos de Tuenti en cada rango, y basta con utilizar el comando NET aplicado a los segmentos descubiertos, para tener una visión bastante completa de toda la red.
Issue 7: Servidores sin actualizar
La parte negativa de que se puedan descubrir muchos servidores con los registros PTR es que permite encontrar servidores perdidos, olvidados, o fuera de la política principal de seguridad porque son de pruebas, temporales, o, incluso, que son dispositivos IP. Mirando alguno al azar, era posible descubrir servidores Apache publicados en servidores accesible por Internet, en los que se muestran las versiones de los productos y, algunos, como en este caso, con vulnerabilidades conocidas, como esta de D.O.S. de fácil explotación con el CVE-2010-1452.
Figura 6: Servidor Sanson.tuenti.com con vulnerabilidades conocidas
Es suficiente con revisar el ChangeLog completo de Apache para ver todos los CVE que le afectan a la versión que estaba publicada.
Issue 8: Los metadatos
No podría dejar de mirar los servidores de Tuenti con la FOCA sin poner un ojo en la recomendación del Esquema Nacional de Seguridad sobre los Metadatos, para ver si estaban haciendo uso de alguna política de limpieza de documentos antes de publicarlos.
Figura 7: Metadatos en documentos publicados en Tuenti
Basta con buscar algunos de los documentos en PDF publicados en Internet, y descubrir nombres de usuarios, versiones del software que han comprado para utilizar en la organización, y quién lo usa, etcétera.
Issue 9: La transferencia de datos del perfil sin HTTPs
Una de las cosas que más problemas genera es la no posibilidad ni por defecto, ni configurándolo, de utilizar conexiones HTTP-s entre el usuario y los servidores de tuenti. Esto hace que cualquier cosa que se transmita pueda ser escuchada y capturada en una red insegura. Quiero centrarme en el término de red insegura, porque a veces los responsables de infraestructuras lo utilizan para pasar responsabilidades de la compañía al usuario – no he dicho que sea el caso de Tuenti -.
Una red insegura es aquella que no ofrece garantías a sus usuarios sobre la seguridad de sus comunicaciones porque no hay garantía que un atacante pueda capturar los datos o manipularlos.
Así, bajo esta definición de redes seguras nos quedarían un puñadito nada más, en las que, por ejemplo entrarían las redes TCP/IP que usan IPSec (con certificados digitales o Kerberos, no con PSK), las redes WiFi que no usan WPA/WPA2-Enterprise con EAP, las redes WIFI con WPA/WP2 con una contraseña no crackeable [WPA/WPA2 Craking] - ya que pueden ser atacadas con man in the middle [Atacar WPA/WPA2 PSK] - y las que se hacen con redes PPTP con SSTP, PPTP con passwords no crackeables y con L2TP/IPSec. El resto serían inseguras.
Eso sí, ésta red “segura” lo sería solo hasta el operador, ya que después no hay garantía ni control más allá de la red, y sucedería lo mismo con la conexión del servidor VPN a los servidors de Tuenti. Además tendríamos que quitar de la lista las conexiones VPN con L2TP/IPsec y PPTP en aquellas redes como hoteles, universidades, etcétera, donde los puertos de conexión estén bloqueados. Las 3G y GPRS deberíamos dejarlas también fuera por los problemas con GSM con A5/0 y A5/1, y por supuesto las redes WPA/WPA2-PSK en las que seamos más de 1 usuario, ya que se podrían hacer ataques de Mitm.
Figura 8: Gráfico de conexiones "seguras"
En este ejemplo, asumiento Internet como red Insegura, los datos del usuario pasarán siempre en abierto, una vez salga de la "red segura" del usuario o de la "red segura del servidor VPN" que usa el usuario.
Tras esta reducción de redes seguras nos queda:
a) Aceptar que el sistema no ofrece privacidad alguna, como en los correos SMTP/POP3, y eso debería dejarse claro cuando se solicitan datos de caracter personal o mensajes privados de los usuarios.
b) Asumir que el servidor se ha diseñado solo para unos pocos afortunados que tienen suerte de que ningún ataque a un Router mueva tráfico a China o algún insider de un operador tenga una tarde graciosa y publique en pastebin los datos de las sesiones de tuenti que pasen por su red.
c) Poner HTTPS con certificados de validación extendida y protocolos de cifrado robustos para extender la seguridad de la red hasta el usuario.
Es por eso, que lo más fácil para mejorara la seguridad es montar HTTP-s y que justificarlo con un “no te conectes desde una red insegura” es una falacia. Evidente, la falta de Http-s en la transferencia de datos no solo afecta a la privacidad de la información intercambiada, como fotos, mensajes, chats, comentarios en muros, etcétera, sino a los datos de la sesión del usuario, lo que hace que sea fácil perpetrar ataques a la cuenta del mismo.
El usuario debe por tanto tener extremado cuidado con la red que utiliza para conectarse, si valora su privacidad y qué datos envía. Este problema, lo han tenido la mayoría, si no todas, de las redes sociales, aunque muchas ya han optado y están optando por poner HTTP-s opcional, cuando menos, para los usuarios más preocupados, y Tuenti lo pondrá no tardando mucho, seguro.
************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************
Te ha faltado un dato acerca del único tema importante del artículo: cuántos servidores tiene tuenti? Porque de lo demás, es como para reirse un poco.
ResponderEliminar@Anónimo, sí, ponme un mail y te paso la lista completa que generé con direcciones IP, nombres y roles de servicios que descubrí.
ResponderEliminarSaludos!
pacopacorropacoso@yahoo.es
ResponderEliminarEs curioso, pero despues de muchos cambios y a finales de 2012, sigo conociendo personas que por una cantidad de dinero, en cosa de 2 horas, te dan la contraseña de tuenti de la direccion de correo que le pidas.
ResponderEliminar¿Que metodo creeis que utilizan?