Mostrando entradas con la etiqueta Twitter. Mostrar todas las entradas
Mostrando entradas con la etiqueta Twitter. Mostrar todas las entradas

miércoles, 26 de septiembre de 2018

Error de la API de Twitter expone mensajes privados de los usuarios

Un error en la API de Twitter expuso los mensajes directos de algunos usuarios a desarrolladores de aplicaciones de terceros no autorizados.



El error que ha dado pie a esta desprivatización de mensajes (si se puede llamar así) ha estado presente desde mayo de 2017 hasta el 10 de septiembre que se descubrió y parcheó.

"Si interactuaba con una cuenta o empresa en Twitter que dependía de un desarrollador que utilizaba la AAAPI para proporcionar sus servicios, es posible que el error haya provocado que algunas de estas interaccione se envíen involuntariamente a otro desarrollador registrado", explica Twitter.
Como funciona el error:

La compañía no ha querido dar muchos datos al respecto, pero si ha aclarado que el error se encontraba en el funcionamiento de la AAAPI propia de la compañía.

"En algunos casos, el error puede haber incluido el envío de ciertos mensajes directos o tweets protegidos a desarrolladores no autorizados", advierten publicamente.

Cabe señalar que el error solo involucra los DM de los usuarios y las interacciones con las empresas que utilizan Twitter para servicios como atención al cliente.

¿Cuantos usuarios están afectados?

A pesar de que no han descubierto ninguna evidencia de que un desarrollador equivocado haya recibido mensajes privados o tweets protegidos, la compañía no puede confirmar que no haya sucedido. Por lo que, potencialmente pueden estar afectadas más de 3 millones de personas (menos del 1% de los usuarios de la red social).

¿Qué puedes hacer si eres uno de los afectados con los que Twitter ha contactado?
 
Esperar. Twitter asegura que ya han contactado con todos los desarrolladores que podrían haber recibidos datos "no deseados" para que, de ser así, los eliminen con la mayor brevedad.


Esto no es más que una demostración más de que la seguridad no es una ciencia exacta y que nunca podemos asegurar estar 100% libre de peligro en Internet, por lo que debemos minimizar el riesgo al mínimo posible.



Daniel Púa
@devploit
dpua@hispase.com

Más información:

Tweet de la compañía al respecto:






miércoles, 30 de agosto de 2017

Cómo se hackean las cuentas de Twitter como la de FC Barcelona y Real Madrid

Recientemente, el grupo 'Our mine' (no la empresa, como la citan algunos medios) ha vulnerado la seguridad de las cuentas oficiales de los equipos de fútbol Real Madrid y FC Barcelona.

Para ponernos en antecedentes, el pasado 23 de Septiembre podía leerse en la cuenta del FC Barcelona un tweet anunciando el fichaje de Di María. Posteriormente el grupo ‘Our Mine’, mediante otro tweet, reclamaba la autoría del hackeo y más tarde, en un tercer tweet, hacía un llamamiento a crear el hashtag #FCBHack. En el caso del Real Madrid fue bastante similar: además de su tweet promocional haciendo un llamamiento a su cartera de servicios, el grupo publicó un tweet anunciando el fichaje de Leo Messi.




Cuando leemos en los medios tradicionales sobre tipo de hackeos, están acompañados de titulares como “Hackeada la cuenta del Real Madrid para anunciar el fichaje de Messi” o “‘Hackean’ las redes del Barça y anuncian la llegada de Di María”. El usuario medio que lee este tipo de noticias tiende a pensar que un grupo de hackers habrá llevado a cabo algún ataque o bien contra la empresa Twitter o directamente contra el Real Madrid. El objetivo de este post es aclarar cómo se suelen producir la mayoría de estas intrusiones de seguridad.

No se conoce de manera oficial cuál fue el vector de entrada de los atacantes en estos dos casos, pero según nuestra experiencia y conociendo algunos casos de primera mano, podemos decir que la gran mayoría se produce en alguno de estos dos escenarios:


Ingeniería social

Es común en este tipo de ataques hacerse con el control de la cuenta mediante ataques de ingeniería social que tengan como objetivo al equipo de social media. En estos casos, los atacantes se suelen hacer con el control total de la cuenta. Como en estos casos solo ha habido publicación de tweets nos hace pensar que no haya sido la técnica utilizada.



Relación de password robadas

Esto ocurre cuando algún servicio web es vulnerado y los atacantes tienen acceso a una base de datos que relaciona email y password. Este listado es comprobado contra Twitter, dando como resultado una horda de usuarios que estarán bajo el control de un atacante y las usará para seguir a la gente que pague por comprar seguidores, publicar tweet promocionales, etc..



Acceso a alguna de aplicaciones conectadas

Hoy en día cualquier usuario de redes sociales cuenta con multitud de aplicaciones con determinados permisos sobre su cuenta, y más aún en este tipo de cuentas que son gestionadas por equipos que se encargan de la promoción de las mismas. Esta política facilita enormemente el control de la seguridad, ya que mediante la interfaz somos capaces de tener una visión de todos los permisos que hemos otorgado. Pero por otro lado, si algunas de estas aplicaciones tuviese un problema de seguridad podría afectarnos.

Según alguno de los casos que hemos gestionado desde Hispasec, aplicaciones de terceros que han sido vulneradas han servido como puerta de entrada para atacantes que han utilizado los permisos de publicación para hacer eco de sus esloganes, troleos, o promoción (como en este caso) por lo que nos hace pensar que esta hipótesis sea la que tenga más fuerza.

Para poder evitar estos desagradables escenarios, recomendamos un control sobre el listado de aplicaciones, reduciendo el listado a las imprescindibles y no dando más permisos que los estrictamente necesarios. Manteneos alerta y rehuir de las aplicaciones extrañas sobre todo cuando soliciten más permisos de los que necesitan para llevar a cabo su función.

Fernando Ramírez
framirez@hispasec.com

martes, 19 de febrero de 2013

Java detrás de los ataques a Apple, Facebook y Twitter

Estos últimos días se han conocido varias noticias de ataques relevantes: los ingenieros de Facebook, Twitter y Apple han sido infectados por malware en las redes internas de estas compañías. Los ataques parecen tener en común varios elementos, pero básicamente, están basados en fallos de seguridad en Java.

El viernes 15 de febrero Facebook publicaba una nota en la que admitía que durante el mes de enero, sistemas (al parecer, portátiles) internos (probablemente de ingenieros) habían sido comprometidos con malware. No aclaraba cuántos. Según cuenta Facebook, una página que trataba sobre el desarrollo para móviles (al parecer iPhoneDevSDK) había sido comprometida. En ella, habían subido un exploit para Java que aprovechaba una vulnerabilidad previamente desconocida y que permitía la ejecución de código. Facebook se apresura a admitir que sus sistemas estaban completamente actualizados y que contaban con un antivirus. Estas medidas son necesarias (en especial la de actualizar) pero, lógicamente, insuficientes.

Poco después, el día 19, Apple también admite un problema de seguridad. De nuevo, sus desarrolladores visitan una web específica para programadores y el plugin de Java hace el resto, infectando los sistemas Mac.

Tanto Facebook como Apple aseguran que no han accedido a datos sensibles de su red y que siguen con las investigaciones. Por su parte, Facebook reportó a Oracle el fallo utilizado y fue corregido en su actualización del 1 de febrero.

Precisamente ese día, Twitter admite algo parecido. Detectaron accesos a sus datos (esta vez los atacantes sí que tuvieron éxito) y los pudieron acceder a las contraseñas (afortunadamente cifradas y salteadas) de 250.000 usuarios. Aunque no acusa directamente a Java, en la misma nota recomiendan la desactivación de Java del navegador.

Un ataque ingenioso

Los 0-day (fallos aprovechados por atacantes antes de que exista parche) solo pueden ser mitigados por la seguridad en profundidad. Curiosamente, las vulnerabilidades de este tipo están siendo muy habituales en los últimos tiempos, mientras que la seguridad en profundidad sigue olvidada en favor del mantra obsoleto que confía ciegamente en el antivirus, cortafuegos y sentido común... herramientas que por sí mismas no solucionan nada.

Introducir un exploit previamente desconocido en una web visitada por programadores es una buena idea. Evidentemente, este fallo no solo afectó a Facebook o Apple, sino que seguro son muchos más los infectados. No se trataría por tanto de un ataque dirigido contra estas empresas, pero sí que quizás "orientado" hacia programadores, con todo lo que ello significa. El truco consistiría en esperar a que las víctimas acudieran a una web, en vez de enviar un enlace, fichero o cualquier otro señuelo como sucede habitualmente. Esto incluso lo hace menos sospechoso y las víctimas pueden sentirse mucho más confiadas en que realmente, "no han hecho nada malo".

Usar un exploit de Java es una garantía de éxito además. Es sencillo de explotar, elude muchas restricciones sin complejidad, y está más que estudiado por la ingeniería de las mafias del malware cómo evitar la inmensa mayoría de los motores antivirus. Por si fuera poco, al esparcirse a través del navegador, se consigue entrar en las redes internas de las compañías sin demasiado esfuerzo. Hoy en día, pensar en que los ataques se producen desde fuera, saltando servidores, cortafuegos, IDS y otras medidas es un concepto muy de los 90. ¿Por qué pelear contra los altos y vigilados muros del castillo, si puedes "aparecer" ya dentro gracias a la magia de las vulnerabilidades en los navegadores? Los ataques se realizan sobre los equipos de escritorio de las personas que ya están en la red interna, y a través del navegador preferiblemente.

¿Por qué no estaban protegidos?

En los últimos meses, se ha advertido desde todos los frentes que es necesario (no recomendable, sino imprescindible) desactivar Java del navegador o activarlo exclusivamente para ejecutar ciertos applets firmados muy concretos. Esta es una buena medida contra los 0-days que han aparecido y aparecerán contra este software. Al parecer, algunos programadores de Facebook, Twitter y Apple no lo tuvieron en cuenta.

Lamentablemente, cualquier compañía puede ser comprometida de esta manera, pero el hecho de que los atacantes hayan tenido éxito a través de un software tan probadamente atacado como Java, hace que piense en que, al menos, podía haberse evitado esta vía sin demasiado esfuerzo y que se le ha puesto muy fácil a los atacantes. Este tipo de incidentes aporta muy mala imagen a las empresas que lo sufren. No hay más que ver el amable eufemismo usado para titular las notas de prensa en las que Twitter y Facebook admiten que han sido atacadas: "Seguimos manteniendo seguros a nuestros usuarios" y "Protegiendo a la gente de Facebook".

Más información:

Keeping our users secure

Protecting People On Facebook

Exclusive: Apple, Macs hit by hackers who targeted Facebook


Sergio de los Santos
Twitter: @ssantosv


sábado, 8 de diciembre de 2012

SMS spoofing en Twitter, un viejo truco


Hace unos días, Jonathan Rudenberg publicaba una vulnerabilidad en el sistema de publicación a través de SMS de Twitter que podría permitir el envío de tweets en nombre de otra persona con solo conocer su número de teléfono. El efecto de esta vulnerabilidad ya se conoce desde hace varios años.

Twitter dispone de una interfaz SMS con la que, a través de mensajes de texto, un usuario puede publicar actualizaciones y seguir a otros usuarios, entre otras opciones. Para activarla, es necesario enviar un nombre de usuario y contraseña a unos códigos telefónicos que la red social dispone a tal efecto. Una vez hecho esto, el número de teléfono queda asociado a la cuenta de Twitter.

Jonathan Rudenberg en su blog afirma que esa asociación puede ser utilizada para publicar en la cuenta de otra persona solo conociendo su número de teléfono. El fallo reside en que la interfaz de Twitter confía en la legitimidad del origen del SMS sin pedir ninguna autenticación adicional.

El número de origen de un SMS puede ser fácilmente falseado. Algunos proveedores permiten cambiar el origen del mensaje de texto, así que es posible que un tercero envíe un mensaje con el número de teléfono de la víctima como origen y que Twitter lo publique en su cuenta asociada.

El usuario puede entonces ejecutar todos los comandos disponibles a través de SMS sobre la cuenta de la víctima, entre lo que se incluye el envío de mensajes directos, respuesta a otros usuario, o incluso desactivar la cuenta por completo si se es usuario exclusivo a través de SMS.

Sin embargo, Moxie Marlinspike, en un post en el blog de ingeniería de Twitter, ha dado algunos detalles de la situación. Para utilizar el canal SMS, el usuario tiene la opción de enviar sus comandos a dos tipos de códigos telefónicos.

El código "corto" es un número menor a cinco cifras, disponible en algunos países y proveedores de red móvil (España, por ejemplo, no tiene). Este es el método que utilizan muchos usuarios de Twitter SMS. Estos códigos funcionan dentro de la misma red del operador y no permite cambiar el origen del mensaje. Por tanto no hay posibilidad de spoofing en este caso.

Sin embargo, el resto de países deben enviar sus tweets a un código "largo". Este es un número telefónico normal que sí es vulnerable a spoofing. Por ello, Twitter ofrece una autenticación a través de PIN a los usuarios de estos códigos desde hace varios años, aunque es necesario que el usuario lo active.

Además, si en un país existe un código corto, no se permite al usuario publicar a través del código largo. Por tanto, el impacto de la vulnerabilidad es de menor magnitud, quedando reducido a solo los usuarios que solo puedan enviar sus tweets a un código largo y además no tengan activado el PIN.

Efecto conocido

Si Twitter ofrece activación por PIN, es porque ya fue vulnerable al falseamiento del remitente del SMS. Ya a principios de 2007, Nitesh Dhanjani daba detalles de este problema, lo que desemboco en la implementación de esta doble autenticación. Posteriormente, en 2009, Lance James se hacía eco del mismo fallo, esta vez solo afectando a usuarios de Reino Unido y Alemania. También SecurityByDefault aprovechó este fallo hace algunos años para realizar una divertida broma, con la que publicó un mensaje en una cuenta tan popular como la de @edans.

Parece que los reportes de la vulnerabilidad se han ido dando en zonas donde aún no había disponibles códigos cortos. Por tanto, la publicación no muestra nada nuevo, simplemente que siguen existiendo zonas donde la red móvil hace posible el spoofing en Twitter si no se tiene activado el PIN.

Este mismo fallo se podía encontrar en Facebook y Venmo, una plataforma social de pagos. Estos fueron solucionados antes de la publicación de la vulnerabilidad y no han trascendido más detalles.

Más información:

SMS Vulnerability in Twitter, Facebook and Venmo

Twitter and SMS Spoofing

Twitter and Jott Vulnerable to SMS and Caller ID Spoofing

Twitter Spoof (Twoof/Tweef?) You decide

Hackeos memorables: El Twitter de Enrique Dans



Francisco López