Mi experiencia hackeando una app de citas (y la forma equivocada de tratar a los investigadores de seguridad)

• Se descubrió una vulnerabilidad de seguridad grave en Cerca, una app de citas
• El OTP quedaba expuesto en la respuesta, por lo que cualquiera que supiera el número de teléfono podía acceder a la cuenta
• Varios endpoints de API abiertos sin autenticación permitían la filtración fácil de información personal
• Se expuso en masa información sensible de los usuarios, como preferencias sexuales, contenido de mensajes e identificaciones oficiales
• A pesar del reporte responsable del investigador, el servicio tuvo una respuesta insuficiente y una comunicación deficiente

---

La importancia de que las startups se tomen la seguridad en serio

• Últimamente, muchas startups se apresuran a salir al mercado y descuidan la seguridad
• Aunque se trata de una app de citas que concentra datos personales, la falta de madurez en desarrollo y operación dejó a los usuarios en riesgo

Descubrimiento de la vulnerabilidad y proceso de notificación

• El 23 de febrero de 2025 se envió a Cerca un correo explicando la vulnerabilidad de seguridad y los problemas relacionados
• El 24 de febrero se discutieron por videollamada los detalles de la vulnerabilidad, las medidas de respuesta y los pasos a seguir
• El equipo de Cerca indicó que entendía la gravedad, que actuaría con rapidez y que notificaría a los usuarios
• Después se enviaron varias consultas sobre el avance, pero al 21 de abril no hubo respuesta ni aviso público
• Según una verificación independiente, la vulnerabilidad ya fue corregida

Vulnerabilidad del OTP y proceso simple de hackeo

• Durante el inicio de sesión en la app, la contraseña de un solo uso (OTP) quedaba expuesta tal cual en la respuesta de red
• Un atacante podía acceder fácil y rápidamente a cualquier cuenta con solo conocer el número de teléfono

Acceso a endpoints de API y filtración de información

• Se confirmó que era posible acceder a todas las rutas de API con solo agregar el header de versión de la app
• A través del endpoint /docs, quedaba expuesta toda la documentación OpenAPI
• Con herramientas como Burp Suite era posible controlar la API inyectando automáticamente headers y tokens de la app
• Algunos endpoints solo modificaban lógica de negocio, pero los principales devolvían datos personales graves
• Con rutas como user/{user_id} era posible obtener información personal, números telefónicos e incluso secuestrar cuentas

Exposición masiva de datos personales e identificaciones oficiales

• A través de endpoints de datos personales se filtró masivamente PII como género, ciudad, fecha de nacimiento, correo escolar e información de identidad oficial
• En particular, campos relacionados con identidad como national_id_verified permitían acceder a archivos sensibles, como imágenes de pasaportes y documentos de identidad
• Con un script de ataque se identificó a 6,117 usuarios, y 207 de ellos incluso habían cargado información de identificación
• Entre las cuentas había algunas que indicaban pertenecer a la Universidad de Yale
• Según el Instagram oficial de Cerca, esto correspondería a 10 mil usuarios en la primera semana

Riesgo de daño real y gravedad del problema

• La filtración de información extremadamente sensible, como preferencias sexuales, conversaciones e identificaciones, implicaba riesgos graves de acoso, robo de identidad y chantaje
• Cerca decía que “cumple con estándares de la industria, incluido el cifrado”, pero eso no coincidía con la realidad de su operación
• Como los usuarios no pueden verificar esto por sí mismos, es esencial que el proveedor de la app gestione la seguridad de forma activa y responsable
• En la práctica, también existe la posibilidad de que personas no identificadas ya hayan robado datos personales a gran escala

Conclusión y necesidad de una cultura de seguridad responsable

• Operar una app tan vulnerable que cualquiera pueda hackearla fácilmente es un problema social grave
• Si la protección de los datos de los usuarios no es la máxima prioridad, el daño puede ocurrir en tiempo real
• El caso de Cerca, que respondió de forma insuficiente al reporte del investigador y comunicó mal a los usuarios, debe servir de advertencia
• Para construir un internet más seguro, establecer una base sólida de seguridad debe ser la prioridad número uno para todos los desarrolladores

[GN⁺]

Opinión de Hacker News

• Incluso considerando que esta app parece el resultado de un trabajo bastante básico de universitarios, creo que aun así debían hacer su mejor esfuerzo tanto en seguridad como en comunicación. Dicho eso, también he visto empresas para adultos financiadas por grandes VC tropezar con problemas como este y reaccionar de forma parecida, así que tampoco creo que haya que ser demasiado duro con estudiantes. Comparto el enlace del artículo

  • No estoy nada de acuerdo. "No sabían" no puede servir como excusa. Haber seguido adelante sin saberlo es aún peor. Es como un conductor inexperto que, sin licencia, provoca un accidente y hiere a alguien
  • Yo también hice clic en el enlace de la fuente buscando más información sobre Cerca, y era un artículo de abril de 2025 alabando una app creada apenas unos dos meses antes. Se siente como basura alucinada por un LLM. Según OP, contactó al equipo de Cerca en febrero, así que o era una vulnerabilidad descubierta apenas salió el producto o aquí hay algo raro. Aun así, sigue estando el hecho de que era una "vulnerabilidad de dos meses" en un "servicio hecho por estudiantes de dos meses"
  • Si la app sale publicada bajo el nombre "Cerca Applications, LLC", no veo cómo la gente podría saber que debería ser más indulgente porque la hicieron estudiantes
  • Estos estudiantes probablemente deberían dedicarse a estudiar otra cosa
  • Esto suena a defenderlos. No debería asumirse que si una app fue hecha por universitarios entonces hay que perdonarla sí o sí. The Facebook también empezó con universitarios. Meta ya tiene una larga historia de abusos a la privacidad e indiferencia hacia la seguridad de los datos. Por eso creo que este tipo de conducta no tiene excusa y que solo se corrige con regulación real y multas, sin importar la edad o experiencia del fundador
  • Si vas a manejar datos sensibles como pasaportes y orientación sexual, como mínimo debes responder cuando te avisan que estás filtrando datos. Esto es un desastre total, y el nivel de ausencia de seguridad aquí es absolutamente inaceptable
  • Si no sabes nada de seguridad de apps, entonces simplemente no deberías hacer una app. Lo digo con mucha frustración, pero ver a amistades usar apps de citas y pensar que su información pueda quedar expuesta es horrible. Quienes la hicieron deberían sentir vergüenza. También deberían avergonzarse por no responder a un investigador de seguridad. Si a mí me hubieran ignorado así, habría escrito una denuncia muchísimo más directa. Ojalá dejen de hacer apps

• Como desarrollador que trabaja en una empresa pequeña, a veces me preocupa mi responsabilidad personal. Muchas empresas operan fuera de ámbitos donde aplican regulaciones como PCI o HIPAA. En organizaciones pequeñas, la seguridad suele verse como una tarea de ingeniería y no como una responsabilidad de toda la organización. El equipo de producto se enfoca en funciones, PM en fechas, QA en bugs, y rara vez hay alguien que alce la voz por la seguridad. El ambiente suele ser que los ingenieros solo hagan lo que se les asigna. Si además pueden cubrir seguridad, qué bueno; si no, incluso reciben críticas de PM y otros. Y siempre se escucha lo mismo: "¿cuánto tiempo va a tomar esto?", "¿qué tan probable es que eso realmente pase?", "saquemos primero el MVP y luego lo arreglamos". Así que al final uno como empleado termina haciendo lo que la empresa le pide. Pero me preocupa seguido si, cuando demanden a la empresa por un hackeo o una filtración, yo termine cargando con la culpa por ser el ingeniero que "debió saber más"

  • En la práctica, como no eres quien firma certificaciones ni quien garantiza formalmente la seguridad, no serás responsable aunque se demuestre que no era seguro
  • Si la empresa es una LLC o una Corp, normalmente te protege el 'corporate veil'. A menos que hayas cometido algo criminal y quede en actas, no deberías tener responsabilidad. Aun así, la falta de estándares de seguridad es un problema enorme en empresas de cualquier tamaño. Siempre se prioriza lanzar funciones nuevas por encima de la seguridad
  • Creo que, como ingenieros en organizaciones pequeñas, sí es nuestra responsabilidad educar al equipo sobre estos riesgos e insistir con fuerza en que se asigne tiempo de desarrollo a seguridad. No es fácil, pero descuidar esto puede poner en riesgo a toda la empresa
  • Yo me aseguraría de conocer la ley lo suficiente para protegerme, respondería por escrito a solicitudes ilegales y también pediría por escrito cualquier aprobación para ignorarlas. Pero en una startup pequeña eso puede ser difícil. Si sintiera que algo no es legal, simplemente renunciaría
  • No me gusta la defensa de "solo seguía órdenes", pero en estos casos conviene dejar todo por escrito: mandar un correo diciendo que hay un problema de seguridad y guardar evidencia de que tu jefe respondió algo como "no te preocupes por eso". Que yo sepa, nunca he visto que un empleado raso tenga responsabilidad legal personal por una filtración de datos. Normalmente nadie responde y la empresa solo paga una multa simbólica
  • Si no eres un ejecutivo de la empresa, no creo que vayas a tener responsabilidad personal
  • En mi experiencia, eso no pasa

• Para reducir la responsabilidad legal del investigador, creo que bastaría con crear otra cuenta o usar un perfil con consentimiento de un amigo para obtener acceso. Ni siquiera haría falta extraer los datos de verdad: por ejemplo, si mi id es 12345 y el de un amigo es 12357, podrías demostrar que puedes acceder a perfiles de otras cuentas usando los ids intermedios. Como ya dijeron muchos, no hace falta llegar a acceder a los datos personales de miles de personas; basta con demostrar y divulgar la vulnerabilidad

  • Esa es la forma estándar y clara que cualquier investigador de seguridad conoce. Puede ser tentador raspar información sensible para "probarlo", pero es innecesario y además hipócrita

• Este texto en sí se siente bastante confuso. Dice que la API que entrega el OTP (contraseña de un solo uso) era tan simple que el OTP quedaba expuesto en la respuesta del servidor, de modo que cualquiera con solo conocer un número de teléfono podía entrar a una cuenta. Si la API era algo como otp/número_de_celular y el OTP venía en la respuesta, entonces parece que bastaba con adivinar el número para obtener también el código. Luego dice que ejecutó un script para enumerar IDs de usuario y detenerse al encontrar 1,000 IDs vacíos seguidos, y así confirmó un total de 6,117 usuarios, 207 documentos de identidad y 19 estudiantes de Yale. Pero acceder así a datos personales ajenos sin consentimiento se parece mucho al caso viejo de weev y el hack a AT&T, que terminó en cárcel. Aunque aquí la escala sea menor, este tipo de investigación es legalmente riesgosa, y me preocupa que el autor no entienda el entorno legal que no protege a los investigadores de seguridad

  • Menciona la parte en la que la API otp/número devolvía directamente el OTP final. Eso significa que si atinabas al número de teléfono, recibías el OTP de inmediato
  • Si lees la acusación original del caso Auernheimer, allí sí había evidencia suficiente de intención criminal, a diferencia de este caso. También se les acusó de haber divulgado datos personales públicamente, así que no es del todo equivalente a lo de aquí

• Tuve una experiencia parecida: intenté reportar un bug en otra app de citas, pero como no respondían cambié el perfil del fundador para que dijera "contáctenme". Lo restauraron desde un respaldo. Años después vi un anuncio de esa app en Instagram y volví a probar; la misma vulnerabilidad seguía ahí. Cualquiera que conozca el endpoint de la API puede obtener privilegios de admin y acceso a todos los mensajes y matches. Estoy pensando si debería volver a contactarlos

  • Sugieren que lo mejor quizá sea escribirles, dejar claro que eres un desarrollador responsable y limitarte a divulgar el problema sin ir más allá

• Creo que las apps deberían pensarlo dos veces antes de recopilar datos sensibles como pasaportes o direcciones. No es algo que pueda minimizarse diciendo "bueno, la hicieron estudiantes"

  • El gobierno del Reino Unido está empeñado en obligar a los sitios porno a pedir identificación, y tengo curiosidad por ver a qué termina llevando eso
  • Si ya pediste información de identidad como el pasaporte, no debería haber ninguna necesidad de exponerla externamente después de capturarla. Si existe una API para mostrar datos del documento en la UI, debería devolver solo los últimos dígitos y no el número completo. En una app de citas, bastaría con devolver si la identidad fue verificada o no, como booleano o enum (no verificado/pasaporte/licencia de conducir). Los sistemas tipo aerolínea donde se debe elegir entre varios documentos son una excepción, pero incluso la app de United muestra solo los últimos dígitos; ojalá las APIs internas también estuvieran restringidas así
  • Comparten un enlace para consultar el GDPR (la normativa europea de protección de datos)
  • Creo que de plano hace falta un servicio de verificación de identidad operado por el gobierno, seguro y privado. O si no, que lo manejen empresas como Apple o Google, que ya funcionan casi como gobiernos
  • En general lo normal sería usar un servicio externo de verificación de identidad, pero me pregunto si esos servicios realmente entregan también la imagen del documento a la app

• Devolver el OTP tal cual en la respuesta de la API es algo demasiado absurdo. No entiendo por qué harían eso

  • Lo hicieron para poder compararlo de inmediato con el valor ingresado en la UI. Si no piensas en seguridad, hasta podría sonar razonable. En una app de citas, donde el volumen de datos personales necesarios es enorme, un error así es espantoso
  • Así reduces de golpe el costo de base de datos
  • Si generas el OTP y luego simplemente devuelves la respuesta de la DB o del caché, en un POC o MVP es fácil que se te pase algo así si trabajas con un modelo improvisado
  • Parece que el OTP quedaba expuesto directamente en la "respuesta a la solicitud de envío de contraseña de un solo uso". Probablemente se deba a que el framework serializaba el objeto completo de la DB y lo devolvía por HTTP
  • Te ahorras una solicitud HTTP y la UX parece más rápida. Pinterest también expuso alguna vez toda la información, incluso el secreto de 2FA, en una API antigua. Lo reporté y hasta me dieron recompensa, pero este tipo de errores también pasa en big tech
  • Yo tampoco lo entiendo. Solo puedo pensar que fue un error hecho para simplificar la construcción del formulario

• Comparten un enlace a otro artículo relacionado de Yale Daily News

• Ojalá existiera una ley que tratara los datos personales como si fueran residuos nucleares de lo peligrosos que son. Si se filtran, la empresa debería quebrar y quienes resulten responsables deberían enfrentar problemas legales serios. Hoy es demasiado fácil recolectar datos de usuarios y, cuando se filtran, solo piden disculpas y siguen como si nada

  • Tratar toda la PII como material nuclear me parece excesivo. Algo como una dirección de correo, usada solo para autenticación o contacto, no es tan grave
  • Tal vez hasta tendría que haber cárcel de cuello blanco para que por fin le presten atención

• Apenas me enteré de la existencia de una herramienta llamada Charle's Proxy en iOS. Antes hacía pentesting buscando strings directamente en el binario de la app. Parece que ayuda muchísimo para analizar apps exclusivas de iOS

  • La recomiendan como buena herramienta (aunque no sirve si hay SSL pinning)