Estaba ayer de camino al CPD del BBVA para una reunión con el equipo cuando Alfonso, uno de los compañeros de SocialBrains, me compartía por Hangouts un pantallazo de uno de los últimos tweets publicados en nuestra cuenta corporativa:
卐
#Nazialmanya#Nazihollanda Bu size ufakbir#OSMANLITOKADI#16Nisan da görüşmek üzere Nemi yazdımTürkçe ÖĞREN#RT
Acompañado, como cabría esperar, de un vídeo de Youtube que ni me he molestado en enlazar.
Por supuesto, sobra decir que ninguno de nosotros lo habíamos escrito, así que Alfonso estuvo a bien cambiar la contraseña de la cuenta mientras yo le decía que más bien lo que parecía era un hackeo proveniente de alguna app con permisos de escritura.
Era muy raro que alguien tuviera verdadera motivación como para comprometer nuestra seguridad, máxime únicamente para publicar un tweet con fines propagandísticos.
Al principio, le pedí que echara un ojo a aplicaciones como TweetOldPost o Botize. La primera, ampliamente utilizada en muchísimos blogs de WordPress, y la segunda, aunque menos probable (por ser un servicio nacido en España), por servirnos de base para automatizar el envío de algunos tweets genéricos.
No tardó en descubrirse el pastel.
Al parecer el problema venía del hackeo a Twitter Counter, un servicio que ofrece precisamente esto: contabilizar el número de compartidos que ha recibido un contenido (un artículo de un blog, un vídeo, lo que queramos) ahí donde la API de Twitter había dejado hace meses de ofrecerlo. Un tema del que ya hablé en su momento (ES), cuyas únicas razones atienden únicamente al negocio de los californianos (curiosamente el analytics disponible en su servicio de publicidad sí tiene acceso a estos datos…).
Se revocó el permiso, se eliminó el tweet, y a seguir el día.
Ecosistema de APIs VS seguridad global
Al llegar al banco estuve hablándolo con algunos chicos de fraude mientras los primeros medios empezaban a publicar la noticia (EN). Por supuesto, no habíamos sido los únicos. Cuentas con bastante más audiencia que la nuestra, de la talla de Marcelo Claure (CEO de Sprint), el Departamento de Salud de U.K., Reuters Japan, Forbes, Blockchain, BBC North America, Duke University o Amnistía Internacional, figuran entre las víctimas.
Y en ningún caso el hackeo ha comprometido directamente la seguridad de sus cuentas.
¿Cómo es posible esto? Gracias al ecosistema de intermediarios que hemos creado.
Un ecosistema basado en el más noble de los objetivos: compartir recursos para que entre todos el resultado sea una suma. Que no necesitamos desarrollar algo si existe ya una API que nos va a permitir utilizarlo en nuestro producto.
Una postura en la que ganamos todos: los pequeños, que de otra manera no tendríamos forma de tener acceso a elementos tan básicos como un blog o una página en Internet, los grandes, que pueden estudiar modelos de negocio ajenos al núcleo principal, destinando parte de sus recursos y desarrollo a ser explotado por terceros, y de paso, los listillos, que únicamente van a necesitar comprometer la seguridad de algún third-party para en la práctica comprometer las cuentas de cientos o miles de potenciales víctimas.
TwitterCounter, en el momento de escribir esta pieza, en mantenimiento (EN), supo aprovecharse de las nuevas políticas de Twitter para encontrar un negocio al que rápidamente muchos otros intermediarios se han sumado.
Se había vuelto de facto la principal alternativa de todos aquellos que hacían uso de botones de compartir en Twitter en los que además se muestra el número de tweets. Bien sea porque directamente el administrador del servicio había creado una instancia en la API de TwitterCounter, bien sea porque el plugin o extensión que el administrador utiliza para mostrar este tipo de botones hacen uso de la API (en el caso de este blog, y por temas de privacidad que ya expliqué en su día, desestimé su uso).
Comprometiendo a este proveedor, han comprometido a todas las cuentas de Twitter que hubieran dado permisos a TwitterCounter. Un riesgo local que se vuelve global gracias a la intermediación y el escalado de privilegios.
En este caso, con el único objetivo de lanzar una campaña de movilización en favor del presidente Erdoğan, que plantea el próximo 16 de Abril un referéndum para abolir algunos de los pocos principios de democracia que aún quedan en Turquía. Y señalando al gobierno holandés como “nazi y fascista”, palabras que salían del presidente turco recientemente. Pero el hackeo podría haber ido a más, habida cuenta de que TwitterCounter pide, entre los permisos para publicar tweets en nuestro nombre, actualizar nuestro perfil y/o saber a quién seguimos y quienes nos siguen.
Cierto es que al menos no tenían acceso a MPs o datos privados de la propia cuenta (email, contraseña…), pero seguramente hemos dado permisos a algún servicio que en su día ha reclamado estos permisos y que ahí sigue, quizás ni tan siquiera en uso.
Un problema que, como seguramente ya se ha percatado, ocurre tanto en Twitter, como en Facebook, en Google y, por supuesto, en las aplicaciones y programas que instalamos en nuestros dispositivos.
Es, como decía en su momento, un problema de confianza. Aceptamos dar una serie de permisos a un tercero a cambio de un servicio. Y puede que la empresa o desarrollador que esté detrás del servicio tenga toda la buena voluntad del mundo, puede que no, puede que como en este caso su servicio se vea comprometido o incluso puede que el servicio acabe siendo revendido a un tercero cuyos objetivos ya no sean tan halagüeños como esperábamos.
Pero el corolario es el mismo: Estamos delegando factores de seguridad en un ecosistema de APIs que no cuenta con las garantías necesarias para ello.
¿Qué podemos hacer para minimizar el riesgo?
- Revisar y revocar acceso a todo aquello que ya no esté en uso: Cada X meses conviene revisar el apartado de permisos de aplicaciones en cuentas como la de Twitter, la de Google, la de Facebook, y por supuesto, en nuestro Android/iOS de turno, por ver si tenemos algún servicio o app que ya no estemos utilizando. Y si es así, eliminarlo. Muchos de los ataques de este tipo se evitan simplemente manteniendo saneada esta sección, que normalmente la encontraremos en Ajustes de Seguridad > Aplicaciones o Permisos de aplicaciones. En el caso que nos compete es tan sencillo como irse a Configuración y Privacidad de nuestra cuenta de Twitter > Aplicaciones, y buscar ahí Twitter Counter o The Counter, revocándoles el acceso hasta nueva orden.
- Exigir por parte de la plataforma un uso proactivo de los permisos que pedimos a la cuenta: De cara a desarrolladores, convendría que estas plataformas les exigiera demostrar que en verdad necesitan dichos datos para que su servicio funcione. Entiendo que esto es más sencillo de implementar en un market de aplicaciones que en un servicio digital que únicamente pide la API de la cuenta de turno para realizar X tarea, pero me parece un punto crítico para evitar el típico escenario de APIs pidiendo permisos para absolutamente todo “por si acaso”.
- El control debe mantenerse en el tiempo: No solo hablamos de que este control se haga en el momento de aprobación de la aplicación, sino también a lo largo del tiempo, quizás cuando una aplicación o servicio se actualice. Además, convendría exigir que cambios de equipo y/o de dirección sean avisados tanto a la plataforma como a los usuarios, por ser estos dos momentos los que habitualmente suponen la mayoría de situaciones de compromiso de cuentas. En casos de hackeo al proveedor, Twitter y el resto de plataformas deberían ser capaces de revocar automáticamente y de forma temporal las peticiones de la API para evitar que el riesgo sea aún mayor.
Son algunos apuntes en caliente sobre el tema, que dibujarían un marco muchísimo más seguro, y también más controlado. Y me da que va a ser el único camino posible, habida cuenta de que los beneficios de un ecosistema de APIs han demostrado ser un gran cambio a mejor dentro de la industria.
P.D.: Es el segundo jueves consecutivo que me salto la pieza que tenía planteada sobre la RootedCon. Pero es lo que hay. La semana que viene espero poder publicarla, aunque no sea el día que tenía pensado, y quizás incluso con dos artículos distintos de esta misma serie.
________
Puede ver más artículos de esta serie en #MundoHacker, donde tratamos en varios tutoriales las medidas para atacar y/o defenderse en el mundo digital.
Y si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
No cabe duda que dejar que una aplicacion trabaje por ti tienes sus riesgos…Ahora bien… ¿No necesitamos todo automatizado o si?…Hay personas que piensan que por estar todo el rato pendiente de sus tweet, o de sus mensajes de facebook, actualizaciones… Pierden efectividad en su trabajo… Y en parte es muy cierto, ahora bien…. Dedicar una hora a programar con plataformas como tweetdeck o otras similiares… Es una buena opcion…A me sigue sin convencer la aplicacion de hotsuite…Nos la estan vendiendo como bombo y platillo….Y no le veo consistencia…. Como dice el dicho “cada maestrillo tiene su librillo”
Claro que no Miguel. Pero cuando los recursos son limitados, hay que tomar decisiones.
En nuestro caso publicamos nosotros la mayoría de Tweets, pero tenemos pre-programado una serie de ellos simplemente para mantener actividad y redifundir los artículos anteriores.
Necesario, realmente, no es. No vivimos de la publicidad, y mucho menos vamos a conseguir nuevos clientes por Twitter. Pero por la misma razón tampoco nos cuesta tener un perfil bajo.
En otros casos (medios de comunicación, por ejemplo), sí se vuelve más necesario, habida cuenta de que su negocio depende, directa o indirectamente, de ello.