La experiencia de hackear una app de citas y la forma equivocada de tratar a los investigadores de seguridad
(alexschapiro.com)- En la app de citas Cerca, la combinación de inicio de sesión basado en número telefónico y una API expuesta la dejaba en un estado riesgoso donde la respuesta del OTP incluía el código de autenticación y podía derivar en la consulta de datos personales
- En
api.cercadating.com, al agregar el encabezado de versión de la app, los endpoints quedaban expuestos a través de openapi.json en/docs, y algunas solicitudes incluso permitían manipular lógica de negocio, como forzar emparejamientos user/{user_id}devolvía PII con solo un ID de usuario válido, incluyendo nombre, ubicación, fecha de nacimiento, escuela, número de teléfono, correo electrónico y estado del perfil, lo que, combinado con la vulnerabilidad del OTP, podía llevar al secuestro de cuentas- Tras acceder a una cuenta, era posible ver información de pasaporte o documento de identidad, URL de selfies e incluso mensajes privados en los usuarios que los hubieran enviado; con un script de verificación se encontraron 6,117 usuarios, 207 que habían ingresado datos de identificación y 19 marcados como estudiantes de Yale
- La vulnerabilidad fue reportada a Cerca el 23 de febrero de 2025 y hubo una llamada el 24 de febrero, pero hasta la divulgación pública del 21 de abril no hubo respuesta de seguimiento ni notificación a los usuarios; solo se confirmó de forma independiente que el fallo había sido corregido
Respuesta interrumpida tras el reporte
- La app de citas Cerca tenía una vulnerabilidad de seguridad que podía exponer mensajes privados, información de pasaporte, preferencias sexuales y otros datos personales
- Tras descubrir la vulnerabilidad, se reportó por correo al equipo de Cerca el 23 de febrero de 2025, y al día siguiente se discutieron en una videollamada la vulnerabilidad, las medidas de mitigación y los pasos a seguir
- El equipo de Cerca reconoció la gravedad del problema, agradeció la divulgación responsable y prometió corregirlo y notificar a los usuarios afectados
- Después se pidió una actualización sobre la corrección y el plan de notificación a usuarios el 5 y el 13 de marzo, pero no hubo respuesta hasta la fecha de divulgación pública, el 21 de abril de 2025
- Antes de la divulgación, se confirmó de forma independiente que la vulnerabilidad había sido parchada, y con base en ello se realizó la publicación
Acceso a cuentas iniciado desde el login OTP
- La app usaba únicamente inicio de sesión por OTP enviando un código al número telefónico
- Para inspeccionar las solicitudes de red, se interceptaron las peticiones de la app de iPhone usando Charles Proxy
- En la respuesta que disparaba el OTP, el código de un solo uso venía incluido directamente
- Con esta estructura, bastaba conocer el número telefónico de un usuario para acceder a su cuenta
- Como se necesitaba una vía adicional para averiguar el número telefónico del titular de la cuenta, se pasó a explorar endpoints de la API
Endpoints expuestos a través de la documentación OpenAPI
- Se enumeraron rutas de
api.cercadating.comusando un directory fuzzer - Sin los encabezados relacionados con la app, no se podía acceder a ninguna parte del sitio
- Al agregar esos encabezados en las solicitudes de Gobuster, se encontró el endpoint
/docs, donde se ofrecíaopenapi.json - Con la función de match-and-replace de Burp Suite, se configuró el agregado automático del encabezado de versión de la app y del bearer token extraído desde Charles Proxy
- Algunos endpoints sin protección afectaban la lógica de negocio, e incluso permitían solicitudes para forzar emparejamientos entre dos personas
Exposición de perfiles de usuario y datos personales
- El endpoint
user/{user_id}devolvía diversos datos personales al recibir un ID de usuario válido - La respuesta incluía la siguiente información
- nombre, género, género de interés, ciudad, latitud y longitud
- correo universitario y estado de verificación, industria, ocupación, fecha de nacimiento, estatura
- ID de la escuela y nombre de la escuela, estado de completitud del perfil
- estado de verificación de identidad por nacionalidad, verificación móvil y de correo
- estado premium, estado de cuenta activa, suspendida y de onboarding
- número de teléfono, correo electrónico, ID de usuario, búsquedas restantes
- imágenes de perfil, preferencias de match, prompts del usuario, información de contacto mutuo, fechas de creación y modificación, edad y más
- Con un script en Python, se podían encontrar IDs de usuario válidos y enumerar masivamente datos de usuarios
- Los números telefónicos devueltos, combinados con la vulnerabilidad del OTP, podían usarse para obtener acceso total a las cuentas
- Los datos personales de los usuarios quedaban expuestos incluso sin iniciar sesión por OTP
Acceso que llegaba hasta documentos de identidad y mensajes privados
- El campo
national_id_verifiedmostraba que el sistema almacenaba información de pasaporte o documento de identidad - La respuesta relacionada con documentos de identidad incluía los siguientes datos
verification_type:PASSPORTdocument_numberfront_side_urlback_side_urlselfie_url- estado, ID, ID de usuario
- Esta información solo se entregaba al usuario autenticado, pero debido a la vulnerabilidad del OTP, existía la posibilidad de iniciar sesión como cualquier usuario
- Se señaló que, para los usuarios que habían enviado documentos, la estructura permitía ver la información de identidad de cualquiera, aunque se aclaró que no se hizo
- También era posible ver mensajes privados con posibles parejas, y en los casos en que se habían enviado, incluso información de pasaporte
Alcance confirmado de la exposición
- Con un script rápido, se contó cuántos usuarios podían revelar información, cuántos aparecían registrados como estudiantes de Yale y cuántos habían ingresado información de identidad
- El script funcionaba contando IDs de usuario válidos y se detenía tras no encontrar ninguno válido durante 1,000 intentos consecutivos
- Este método no descarta la posibilidad de que hubiera más usuarios
- Cerca dijo que había tenido 10,000 usuarios en su primera semana
- Las cifras confirmadas fueron las siguientes
- 6,117 usuarios
- 207 usuarios que habían ingresado información de identidad
- 19 usuarios marcados como estudiantes de Yale
La promesa de privacidad y el riesgo real
- La política de privacidad de Cerca afirma que “protege los datos con cifrado y otras medidas estándar de la industria”
- Comparada con el estado real de la vulnerabilidad, esta frase resulta engañosa
- Entre los datos expuestos podían estar preferencias sexuales, mensajes privados y diversos datos personales
- Si un actor malicioso accedía a esa información, podía derivar en robo de identidad, acoso o extorsión
- Como las apps de citas manejan datos sensibles, la seguridad de los datos de los usuarios debe estar por encima de la velocidad de lanzamiento de la app
1 comentarios
Opiniones de Hacker News
Esta app parece un proyecto bastante inicial hecho por universitarios. Es cierto que deberían esforzarse al máximo por seguir buenas prácticas de seguridad y comunicación, pero considerando que incluso “empresas adultas” con grandes inversiones de VC responden pésimo ante problemas similares, tampoco quiero caerles con demasiada dureza.
https://georgetownvoice.com/2025/04/06/georgetown-students-c...
Es parecido a cuando un conductor mata a alguien en un accidente y luego resulta que ni siquiera tenía licencia.
El post original dice que contactaron al equipo de Cerca en febrero, así que o fue una falla descubierta el día del lanzamiento o hay algo raro en la estructura. En cualquier caso, es una “vulnerabilidad de dos meses” y una “app/servicio de estudiantes de dos meses”.
Además, no es algo hecho por diversión, sino un producto comercial. En la app aparecen compras integradas como Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99 y 5 Searches $2.99.
Como ingeniero en una empresa chica, a veces me preocupa mi responsabilidad personal. Hay muchísimas empresas que operan en sectores no regulados donde no aplican PCI ni HIPAA, y en organizaciones pequeñas la seguridad no se trata como una obligación de toda la organización, sino que queda relegada a un simple interés de ingeniería.
El equipo de producto se enfoca en funcionalidades, los PM en los plazos, QA en encontrar bugs, y rara vez hay alguien que alce la voz de forma razonable sobre seguridad. De los ingenieros no se espera mucho más que terminar las tareas que están en el tablero. Si se puede hacer seguro sin afectar el cronograma, genial; si no, empiezan las presiones de los PM y otros.
Uno escucha cosas como “¿cuánto se tarda eso?”, “¿cuál es el riesgo real de que pase?”, “arreglemos la seguridad después y primero saquemos el MVP a los clientes”. Como empleado, hago lo que me pide mi empleador, pero si hackean la empresa o hay una filtración de datos y la demandan, me pregunto si yo terminaría siendo personalmente responsable por ser la única persona que “debería haberlo sabido”.
Dicho eso, la falta de estándares de seguridad en toda la organización, sin importar el tamaño, es lamentable. Parece que lanzar nuevas funciones siempre tiene prioridad sobre garantizar buenas prácticas de seguridad.
Dicho eso, entiendo que en una startup con solo uno o dos desarrolladores incluso eso puede ser difícil. Si siento que no se busca hacer las cosas legalmente, yo me iría.
No es fácil, pero es algo importante que, si no se toma en serio, puede hundir todo el negocio.
Necesitas un historial de correos donde hayas planteado preocupaciones por la falta de seguridad y una respuesta de tu jefe diciendo que no le des importancia. No sé en qué jurisdicción estés, pero no conozco casos en los que un empleado común haya sido legalmente responsable a título personal por una filtración de datos. Normalmente nadie enfrenta consecuencias reales por una filtración de datos, y la empresa paga una multa simbólica y sigue adelante.
Como investigador, para reducir la exposición legal habría bastado con crear una segunda cuenta o pedirle a un amigo que hiciera un perfil y diera su consentimiento de acceso.
No hace falta raspar datos reales para demostrar una vulnerabilidad de enumeración. Si mi ID es 12345 y un amigo se registra y recibe el 12357, eso basta como prueba de que se puede encontrar el ID de cualquier usuario y acceder a su perfil.
Como dijeron otros, no hace falta acceder a tanta información de identificación personal de otros usuarios para verificar y divulgar la vulnerabilidad.
Querer que la información de identificación personal esté protegida y, aun así, rasparla para demostrarlo es innecesario e hipócrita.
El texto es bastante confuso. En la parte del inicio de sesión basado en OTP, dice que en la respuesta a la solicitud de la contraseña de un solo uso viene el OTP tal cual; falta explicación, pero probablemente se refiere a que era una API como api.cercadating.com/otp/, así que si adivinabas un número de teléfono podías recibir el código OTP aunque no fueras dueño de ese número.
También dice que, con un script que se detenía si no encontraba usuarios válidos en 1,000 IDs consecutivos, encontró 6,117 personas, 207 con información de identificación y 19 que afirmaban ser estudiantes de Yale; no sé si el autor entiende lo peligroso que es eso. En la práctica se parece a la forma en que weev vulneró AT&T, y él terminó en la cárcel[0].
Aunque era una empresa más grande y una filtración mayor, no creo que uno deba presumir públicamente que accedió sin autorización a los datos de miles de personas aprovechando un agujero de seguridad. No intento juzgar la moralidad, y creo que debe haber margen para que los investigadores de seguridad adviertan sobre problemas, pero la ley es bastante desfavorable para ellos.
[0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...
A los acusados de ese caso también se les imputó haber publicado información personal identificable subyacente, y aquí no parece que haya ocurrido algo así.
Me pasó algo parecido con otra app de citas, y ellos nunca respondieron. Para llamar la atención del fundador, cambié su perfil para que dijera “contáctenme”, y entonces restauraron un respaldo.
Años después vi un anuncio en Instagram y revisé si el problema seguía ahí; seguía. Con solo conocer un endpoint de API que era fácil de encontrar con app-proxy-servidor, cualquiera podía tener permisos completos de administrador y acceder a todos los mensajes, matches, etc.
Me pregunto si debería volver e intentarlo una vez más.
Antes de pedir información sensible como pasaportes o direcciones, deberían obligar a la gente a pensarlo dos veces. Esto no se puede descartar simplemente como niños haciendo una app.
En un sitio de citas, basta con que la API devuelva un booleano verified/not-verified sobre el estado del documento, o un valor enumerado como ‘not-verified’, ‘passport’, ‘drivers-license’. No hay una necesidad real de mostrar detalles en el cliente/UI.
Casos como apps de aerolíneas, donde debes elegir un documento de identidad para fines migratorios, podrían ser excepciones y mostrar más información, pero bastaría con mostrar solo los últimos dígitos del pasaporte, como en la app de United. Ojalá también envíen solo eso por las API internas.
O, si no, que lo maneje algún actor “parecido a un gobierno” como Apple o Google.
https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
Que la respuesta de la API de solicitud devuelva el OTP no tiene sentido. ¿Por qué lo habrán hecho así?
Si no piensas en seguridad, es una solución muy plausible y obvia. Una app de citas es necesariamente uno de los tipos de app más riesgosos de construir porque contiene mucha información personal identificable, y esto es terrible.
En una prueba de concepto rápida o un MVP, muchas veces se usa el modelo almacenado directamente como respuesta de la API para ahorrar tiempo, así que es algo fácil de pasar por alto.
Cuando salió la nueva API de Pinterest, estaba repartiendo toda la información de usuario a todas las apps que usaban la integración OAuth, e incluso incluía el secreto de autenticación de dos factores. Lo reporté y recibí una recompensa, pero este tipo de cosas también pasan en APIs de grandes empresas que deberían saberlo mejor.
Es posible que fuera culpa del framework. Probablemente tenían una estructura en la que el objeto que metían en la base de datos se serializaba directamente desde el ORM u otro sistema de almacenamiento y se devolvía como respuesta HTTP.
https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
Otro artículo sobre este caso.
Ojalá hubiera una ley que hiciera que almacenar información personal identificable fuera tan peligroso como almacenar residuos nucleares. Si hay una filtración, la empresa debería casi con seguridad quebrar y los responsables deberían enfrentar riesgos legales.
Creo que esa es la mejor forma de alinear bien los incentivos. Hoy casi no hay desventajas por almacenar tanta información de usuarios como sea posible. ¿Filtración de datos? Publicas un tuit de disculpa y sigues adelante.
Así este problema recibiría la atención que merece.
Si “no recibiste ninguna respuesta”, es momento de avisar que, si el silencio continúa, publicarás la vulnerabilidad después de 90 días