Entrada

Cómo encontramos TeaOnHer derramando usuarios' licencias de conducir en menos de 10 minutos

a speckled photo of the TeaOnHer app

Créditos de la imagen: TeaOnHer (modificada)

Para una aplicación que se dedica a revelar quiénes están supuestamente saliendo, es irónico que TeaOnHer haya filtrado la información personal de miles de sus usuarios a la web.

TeaOnHer estaba diseñada para que los hombres compartan fotos e información sobre mujeres con las que supuestamente han salido. Pero, al igual que Tea, la aplicación de chismes de citas para mujeres, que intentaba replicar, TeaOnHer tenía grandes agujeros en su seguridad que expusieron la información personal de sus usuarios, incluyendo fotos de sus licencias de conducir y otros documentos de identidad emitidos por el gobierno, como TechCrunch informó la semana pasada.

Estas aplicaciones de comunidad cerrada fueron creadas supuestamente para permitir a los usuarios compartir información sobre sus relaciones bajo el pretexto de la seguridad personal. Sin embargo, el código deficiente y las fallas de seguridad ponen de manifiesto los riesgos continuos de privacidad inherentes en la necesidad de que los usuarios envíen información sensible para usar aplicaciones y sitios web.

Estos riesgos solo van a empeorar; las aplicaciones y servicios web populares ya tienen que cumplir con las leyes de verificación de edad que requieren a las personas presentar sus documentos de identidad antes de que se les permita acceder a contenido para adultos, a pesar de los riesgos de privacidad y seguridad asociados con almacenar bases de datos de la información personal de las personas.

Cuando TechCrunch publicó nuestra historia la semana pasada, no publicamos detalles específicos de los errores que descubrimos en TeaOnHer, optando por la precaución para no ayudar a los actores malintencionados a explotar el error. En su lugar, decidimos publicar una revelación limitada, debido a la creciente popularidad de la aplicación y los riesgos inmediatos que enfrentaban los usuarios al usar la aplicación.

Al momento de la revelación, TeaOnHer estaba en el puesto #2 en las listas de aplicaciones gratuitas de la App Store de Apple, una posición que aún mantiene la aplicación hoy.

Los errores que encontramos parecen estar resueltos. TechCrunch puede compartir ahora cómo fuimos capaces de encontrar las licencias de conducir de los usuarios en menos de 10 minutos después de recibir un enlace a la aplicación en la App Store, gracias a errores fáciles de encontrar en el sistema de backend público de la aplicación, o API.

El desarrollador de la aplicación, Xavier Lampkin, no respondió a múltiples solicitudes de comentario después de que enviáramos detalles de los errores de seguridad, ni se comprometió a notificar a los usuarios afectados de TeaOnHer ni a los reguladores del estado sobre el desliz de seguridad.

También preguntamos a Lampkin si se llevaron a cabo revisiones de seguridad antes de que se lanzara la aplicación TeaOnHer, pero no recibimos respuesta. (Tendremos más sobre la revelación más tarde.)

Vamos a comenzar el cronómetro.

Antes de descargar la aplicación, primero queríamos descubrir dónde estaba alojada TeaOnHer en la web buscando su infraestructura pública, como su sitio web y cualquier cosa alojada en su dominio.

Esto suele ser un buen lugar para empezar, ya que ayuda a entender qué otros servicios están conectados al dominio en la web.

Para encontrar el nombre de dominio, primero miramos (por casualidad) en la lista de la aplicación en la App Store de Apple para encontrar el sitio web de la aplicación. Esto generalmente se puede encontrar en su política de privacidad, que las aplicaciones deben incluir antes de que Apple las liste. (La lista de la aplicación también afirma que el desarrollador “no recopila ningún dato de esta aplicación”, lo cual es claramente falso, así que tómelo como quiera.)

La política de privacidad de TeaOnHer estaba en forma de un documento de Google publicado, que incluía una dirección de correo electrónico con un dominio de teaonher.com, pero sin sitio web.

El sitio web no estaba público en ese momento, por lo que sin sitio web cargado, miramos los registros de DNS públicos del dominio, que pueden ayudar a identificar qué más está alojado en el dominio, como los servidores de correo electrónico o el alojamiento web. También queríamos buscar cualquier subdominio público que el desarrollador pueda usar para alojar funcionalidad para la aplicación (o alojar otros recursos que probablemente no deberían ser públicos), como paneles de administración, bases de datos o otros servicios web accesibles.

Pero cuando miramos los registros públicos de internet de TeaOnHer, no había información significativa más allá de un único subdominio, appserver.teaonher.com.

Cuando abrimos esta página en nuestro navegador, lo que se cargó fue la página de inicio para el API de TeaOnHer (para los curiosos, subimos una copia aquí). Un API simplemente permite que las cosas en la web se comuniquen entre sí, como enlazar una aplicación con su base de datos central.

Fue en esta página de inicio que encontramos la dirección de correo electrónico y la contraseña en texto plano (que no estaba muy lejos de “contraseña”) para el acceso de Lampkin al panel de administración de TeaOnHer. “localhost”, que simplemente se refiere a la computadora física que ejecuta el servidor y que puede no ser directamente accesible desde la web. No está claro si alguien podría haber usado las credenciales para acceder al panel de administración, pero esto fue en sí mismo un hallazgo suficientemente alarmante.

En este punto, solo habíamos pasado dos minutos.

La página de inicio del API no hizo mucho más que ofrecer alguna indicación de lo que el API puede hacer. La página enumeraba varios puntos de finalización de API, que la aplicación necesita para acceder en orden de funcionar, como obtener registros de usuarios de la base de datos de TeaOnHer, para que los usuarios dejen reseñas y envíen notificaciones.

Con el conocimiento de estos puntos de finalización, puede ser más fácil interactuar directamente con el API, como si estuviéramos imitando la aplicación misma. Cada API es diferente, por lo que aprender cómo funciona una API y cómo comunicarse con ella puede llevar tiempo, como cuáles puntos de finalización usar y los parámetros necesarios para hablar su idioma. Las aplicaciones como Postman pueden ser útiles para acceder y interactuar directamente con APIs, pero esto requiere tiempo y una cierta cantidad de ensayo y error (y paciencia) para que las APIs escupan datos cuando no deberían.

Pero en este caso, había una forma aún más fácil.

Esta página de inicio del API incluía un punto de finalización llamado /docs, que contenía la documentación automáticamente generada del API (impulsada por un producto llamado Swagger UI) que contenía la lista completa de comandos que se pueden realizar en el API.

Esta página de documentación era esencialmente una hoja de cálculo maestra de todas las acciones que se pueden realizar en el API de TeaOnHer, tanto como usuario regular de la aplicación como administrador, como crear nuevos usuarios, verificar los documentos de identidad de los usuarios, moderar comentarios y más.

La documentación del API también permitía consultar el API de TeaOnHer y devolver datos de usuario, esencialmente permitiéndonos recuperar datos de la base de datos de la aplicación y mostrarlos en nuestro navegador.

Aunque no es inusual que los desarrolladores publiquen su documentación de API, el problema aquí era que algunos puntos de finalización de API se podían hacer sin ninguna autenticación — no se necesitaban contraseñas ni credenciales para devolver información de la base de datos de TeaOnHer. En otras palabras, podías ejecutar comandos en el API para acceder a los datos privados de los usuarios que no deberían haber sido accesibles para un usuario de la aplicación, ni siquiera para nadie en la web.

Todo esto estaba convenientemente y públicamente documentado para que cualquiera lo viera.

Solicitar una lista de usuarios actualmente en la cola de verificación de identidad de TeaOnHer, por ejemplo — no más que hacer clic en un botón en la página del API, nada complicado — devolvería docenas de registros de cuentas de personas que recently se habían unido a TeaOnHer.

Los registros devueltos desde el servidor de TeaOnHer contenían identificadores únicos de usuario dentro de la aplicación (esencialmente una cadena de letras y números aleatorias), su nombre de pantalla público, y la edad y ubicación autoinformadas, junto con su dirección de correo electrónico privada. Los registros también incluían enlaces web que contenían fotos de las licencias de conducir y las selfies correspondientes de los usuarios.

Peor aún, estas fotos de licencias de conducir, documentos de identidad emitidos por el gobierno y selfies estaban almacenadas en un servidor de Amazon S3 en la nube, configurado como públicamente accesible para cualquiera con sus enlaces web. Esta configuración pública permite a cualquiera con un enlace a los documentos de identidad de alguien abrir los archivos desde cualquier lugar sin restricciones.

Dos licencias de conducir, una de Texas y la otra de Massachusetts, borradas por TechCrunch, que fueron expuestas por la aplicación TeaOnHer.

Dos licencias de conducir (borradas por TechCrunch) expuestas por los errores en la aplicación TeaOnHer.

Con ese identificador único de usuario, también podíamos usar la página del API para buscar directamente los registros individuales de los usuarios, lo que devolvería sus datos de cuenta y cualquier documento de identidad asociado. Con acceso no restringido al API, un usuario malintencionado podría haber raspado grandes cantidades de datos de usuario de la aplicación, similar a lo que ocurrió con la aplicación Tea al principio.

Desde el grano hasta la taza, eso fue aproximadamente 10 minutos, y ni siquiera habíamos iniciado sesión en la aplicación. Los errores eran tan fáciles de encontrar que sería pura suerte si nadie malintencionado los encontrara antes que nosotros.

Preguntamos, pero Lampkin no dijo si tiene la capacidad técnica, como registros, para determinar si alguien había usado (o abusado) el API en algún momento para obtener acceso a los documentos de verificación de los usuarios, como raspando enlaces web del API.

En los días desde nuestra notificación a Lampkin, la página de inicio del API se ha eliminado, junto con su página de documentación, y ahora solo muestra el estado del servidor en el que se ejecuta el API de TeaOnHer como “saludable”. Al menos en pruebas cursorias, el API ahora parece depender de la autenticación, y las llamadas anteriores realizadas usando el API ya no funcionan.

Los enlaces web que contenían los documentos de identidad subidos por los usuarios también se han restringido de la vista pública.

Dado que TeaOnHer no tenía sitio web oficial en el momento de nuestros hallazgos, TechCrunch contactó la dirección de correo electrónico lista en la política de privacidad en un esfuerzo por revelar los lapsos de seguridad.

Pero el correo electrónico rebotó con un error diciendo que la dirección de correo electrónico no se podía encontrar. También intentamos contactar a Lampkin a través de la dirección de correo electrónico en su sitio web, Newville Media, pero nuestro correo electrónico rebotó con el mismo mensaje de error.

TechCrunch contactó a Lampkin a través de un mensaje de LinkedIn, pidiéndole que proporcionara una dirección de correo electrónico donde podíamos enviar detalles de los errores de seguridad. Lampkin respondió con una dirección de correo electrónico general de “soporte” en respuesta.

Cuando TechCrunch revela un error de seguridad, contactamos primero para confirmar que una persona o empresa es el destinatario correcto. De lo contrario, enviar detalles de un error de seguridad a la persona incorrecta podría crear un riesgo. Antes de compartir detalles específicos de los errores, preguntamos al destinatario de la dirección de correo electrónico de “soporte” si esta era la dirección correcta para revelar una exposición de seguridad que involucra datos de usuarios de TeaOnHer.

“Debes haberte confundido con ‘la aplicación Tea’,” respondió Lampkin por correo electrónico. (No lo habíamos hecho.) “No tenemos una brecha de seguridad o fuga de datos,” dijo. (La había.) “Tenemos algunos bots, pero no hemos crecido lo suficiente como para estar en esa conversación aún, lo siento por la información incorrecta.” (No lo habíamos hecho)

Satisfechos de haber establecido contacto con la persona correcta (aunque no con la respuesta que recibimos), TechCrunch compartió detalles de los errores de seguridad, así como varios enlaces a licencias de conducir expuestas y una copia de los datos de Lampkin para subrayar la gravedad de los problemas de seguridad.

“Gracias por esta información. Esto es muy preocupante. Vamos a saltar sobre esto ahora mismo,” dijo Lampkin.

A pesar de varios correos electrónicos de seguimiento, no hemos recibido respuesta de Lampkin desde que revelamos los errores de seguridad.

No importa si eres una tienda de software de una sola persona o un vibe de billonario codificando a través de un fin de semana: los desarrolladores aún tienen la responsabilidad de mantener los datos de sus usuarios seguros. Si no puedes mantener los datos privados de tus usuarios seguros, no los construyas.

Si tienes evidencia de una aplicación o servicio popular filtrando o exponiendo información, contáctanos. Puedes contactar a este reportero de manera segura a través de un mensaje encriptado en zackwhittaker.1337 en Signal.

Esta entrada está licenciada bajo CC BY 4.0 por el autor.