Encontré una vulnerabilidad. Ellos encontraron a un abogado

• El autor, instructor de buceo e ingeniero de plataformas, descubrió una grave vulnerabilidad de seguridad en el portal de miembros de una aseguradora de buceo
• El portal usaba IDs de usuario secuenciales y la misma contraseña predeterminada, por lo que cualquiera podía acceder a los datos personales de otros miembros con una combinación simple
• Reportó el problema simultáneamente a CSIRT Malta y a la entidad correspondiente, pero la entidad, en lugar de agradecer la auditoría, advirtió sobre una posible responsabilidad penal a través de sus representantes legales
• El autor rechazó la exigencia de firmar un acuerdo de confidencialidad (NDA) y propuso una declaración corregida que solo confirmara la eliminación de los datos, pero la entidad volvió a amenazar alegando posible difamación
• El caso muestra la importancia de un proceso responsable de divulgación de vulnerabilidades y cómo las amenazas legales desalientan la protección de los investigadores

---

Descubrimiento de la vulnerabilidad

• Durante un viaje de buceo a la Isla del Coco, en Costa Rica, descubrió una falla estructural en el portal de miembros de una aseguradora de buceo
  • Cuando un instructor registraba a un estudiante, el sistema generaba un ID numérico secuencial y una contraseña predeterminada que no se cambiaba
  • Como muchos usuarios no cambiaban la contraseña, era posible acceder a toda la información personal de otros miembros (nombre, dirección, fecha de nacimiento, contacto, etc.)
• No existía ninguna medida básica de seguridad como forzar el cambio de contraseña, limitar intentos de inicio de sesión o MFA
• Algunas cuentas incluso contenían información de menores de edad (14 años)
• El autor verificó el problema con acceso mínimo, se detuvo de inmediato y eliminó permanentemente todos los datos recopilados

Verificación y prueba

• Intentó hacerlo con Python requests, pero como la estructura de sesión era compleja, lo verificó mediante automatización del navegador con Selenium
  • Bastaba con ingresar el ID de usuario y la contraseña predeterminada para iniciar sesión
  • El script de automatización se publica como código de ejemplo no funcional, y todos los identificadores reales fueron eliminados
• El ejemplo de salida incluía todos los datos del perfil, como nombre, correo, dirección y fecha de nacimiento
• En este proceso se confirmó que varias cuentas de menores también quedaban expuestas de la misma manera

Proceso de divulgación de la vulnerabilidad

• El 28 de abril de 2025 reportó oficialmente la vulnerabilidad y fijó un plazo de 30 días para corregirla
• Notificó por correo electrónico tanto a CSIRT Malta como a la entidad correspondiente
  • El informe incluía un resumen del problema, posible incumplimiento del GDPR, capturas de pantalla y un enlace cifrado al PoC
  • Solicitó confirmación de recepción en 7 días y corrección en 30 días
• Este era un procedimiento estándar acorde con la política nacional de divulgación de vulnerabilidades (NCVDP)

Respuesta de la entidad

• Dos días después respondió, no el equipo de TI, sino un abogado responsable de protección de datos (despacho legal del DPO)
  • Mencionó el restablecimiento de contraseñas y la introducción de 2FA, pero cuestionó que primero se hubiera informado a una entidad gubernamental
  • Advirtió que la conducta del autor podría constituir un delito según el código penal maltés, con posible responsabilidad legal
• La entidad exigió la firma de una declaración de confidencialidad, junto con una copia del pasaporte y plazo para firmar ese mismo día
  • La declaración incluía una cláusula de “mantener en secreto el contenido de esta declaración”, en la práctica una NDA (acuerdo de confidencialidad)
• Después siguieron solicitudes repetidas de firma bajo títulos como “recordatorio amistoso” y “aviso urgente”

Rechazo y refutación del investigador

• El autor se negó a firmar la cláusula de confidencialidad y en su lugar propuso una declaración corregida que solo confirmara la eliminación de los datos
  • Aclaró que informar a CSIRT Malta era parte del procedimiento oficial, y que analizar el caso tras la divulgación es una práctica estándar en la industria de seguridad
• La entidad citó el artículo 337E del código penal (abuso informático) y advirtió que incluso actos cometidos en el extranjero podrían considerarse delitos en Malta
• También notificó que si mencionaba el nombre de la entidad en un blog o conferencia, podría enfrentar demandas por difamación y daños
• Actualmente la vulnerabilidad ya fue corregida y se está avanzando en el restablecimiento de contraseñas predeterminadas y la implementación de 2FA
• Sin embargo, no está confirmado si se notificó a las víctimas conforme a los artículos 33 y 34 del GDPR

Trasladar la responsabilidad y violación del GDPR

• La entidad sostuvo que “cambiar la contraseña es responsabilidad del usuario”
• Pero según el artículo 5(1)(f) y el artículo 24(1) del GDPR, el responsable del tratamiento debe aplicar medidas técnicas y organizativas adecuadas
• Usar la misma contraseña predeterminada junto con IDs secuenciales constituye claramente una medida de seguridad inadecuada

Un patrón que se repite

• Sigue existiendo el “efecto amedrentador” (Chilling Effect) por el cual los investigadores de seguridad que divulgan vulnerabilidades de forma responsable reciben amenazas legales
• Responder por la vía legal empeora la reputación, y el problema no es la vulnerabilidad en sí, sino la forma en que la organización responde

Procedimiento correcto de respuesta

• Recibir el reporte y corregir el problema
• Agradecer al investigador
• Establecer una política de CVD (Coordinated Vulnerability Disclosure)
• Notificar a los usuarios afectados, especialmente para proteger a menores
• No imponer silencio mediante NDA

Consejos para organizaciones e investigadores

• Las organizaciones deben preparar procedimientos claros de divulgación, como security.txt, y agradecer a los investigadores
• Los investigadores deben involucrar al CSIRT nacional, conservar todos los registros y rechazar acuerdos de confidencialidad tras eliminar los datos
• La directiva NIS2 fomenta la divulgación responsable de vulnerabilidades dentro de la UE
• Incluso en 2026, sigue existiendo la realidad de que un simple reporte de vulnerabilidad puede derivar en amenazas legales

[GN⁺]

Comentarios de Hacker News

• Ha habido casos de otras personas que encontraron IDs de usuario monotónicamente crecientes y, por probarlos, terminaron en la cárcel
  En el momento en que haces ese tipo de prueba, surge el riesgo de violar la CFAA
  Si ya sabías que los IDs eran monotónicamente crecientes y que había una contraseña predeterminada configurada, en ese punto debiste reportar la vulnerabilidad de inmediato
  En el momento en que ejecutaste la prueba, podrías haber infringido la ley
  Escribir esto ahora es prácticamente una confesión, así que deberías contratar a un abogado y estudiar la ley correspondiente

• No tengo experiencia legal, pero tengo tres ideas

  1. Si el proceso de divulgación legal es demasiado difícil, al final solo nos enteraremos de las vulnerabilidades por medio de criminales
  2. En otras industrias no tendría sentido que demandaran a un arquitecto por descubrir una falla en un edificio. Pero la ciberseguridad es distinta en que conocer una falla en sí mismo aumenta el riesgo
  3. Que una persona al azar que iba pasando haga una auditoría es demasiado inestable. Si un sitio web me pide mi PII (información de identificación personal), debería tener derecho a exigir la seguridad de esa información
     Lugares como las aseguradoras deberían estar obligados por ley a pasar auditorías cibernéticas, proteger a los hackers white hat y permitir que los usuarios presenten demandas colectivas
     Si eso ocurriera, las vulnerabilidades básicas desaparecerían y los ingenieros de software serían más rentables que los abogados
  • En otras industrias existe el sistema de ingenieros profesionales con responsabilidad legal
    Me pregunto si en CS también iremos en esa dirección en la era de la IA
    Los ingenieros profesionales se encargan de aprobar diseños e inspecciones, y cumplen un papel clave para garantizar la seguridad
    Por eso tienen tanto autoridad como responsabilidad, y también una remuneración alta
  • En otras industrias, los diseñadores tienen seguro y licencia
    No quisiera impedir la actividad open source de desarrolladores principiantes, pero creo que los sitios que manejan grandes volúmenes de datos personales o dinero deberían requerir la firma de un ingeniero de software certificado
    Así tendrían la capacidad de frenar exigencias irrazonables de la gerencia
    Claro, viendo casos como Boeing o Volkswagen, no es una solución perfecta
  • En algunos países, incluso la verdad puede considerarse difamación
    Es decir, reportarlo a las autoridades y hacerlo público en la prensa son asuntos completamente distintos
    Especialmente en lugares como Malta, donde el crimen organizado y la corrupción son graves, la persona que revele algo así podría sufrir un “accidente”

• Yo uso una dirección de correo distinta para cada servicio
  Hace unos 15 años empecé a recibir spam en la dirección de diversalertnetwork
  Le avisé a DAN sobre la filtración y solo recibí un correo pidiéndome cambiar la contraseña
  Me considero afortunado de no haber recibido una denuncia penal

  • Eso pudo haber sido un hackeo, o la empresa pudo haber vendido los datos a un tercero
  • A mí me pasó algo parecido. Empezó a llegar spam a un correo exclusivo para una aerolínea portuguesa, y la empresa no respondió nada

• El hecho de que el autor tenga miedo de revelar el nombre de la organización significa que las amenazas legales fueron efectivas

  • O quizá, dentro de la comunidad de buceo, la expresión “aseguradora para buzos con sede en Malta” ya implica DAN Europe
  • Por las pistas del texto, entre las aseguradoras internacionales de buceo registradas en Malta, prácticamente solo puede ser DAN Europe
  • Claro, tampoco puede descartarse la posibilidad de que haya vendido la información a black hats

• Sobre la exigencia de “firmar un certificado de eliminación de datos”, me pregunto por qué firmó
  La empresa parece haber querido más control que cooperación

  • Pero si logras que la otra parte acepte tus condiciones, desactivas su estrategia de control y obtienes fuerza legal vinculante

• El patrón de que investigadores de seguridad reporten vulnerabilidades y luego reciban amenazas legales se ha repetido durante décadas
  Gobiernos y empresas hablan de la importancia de la ciberseguridad, pero en la práctica son hostiles hacia los investigadores
  Hace falta legislación para impedir este tipo de respuestas injustas
  Se pueden ver casos relacionados en este enlace

• Me pregunto si el objetivo de este caso es DAN Europe y su subsidiaria IDA Insurance Limited

  • En otro comentario ya llegaron a esa misma conclusión

• En Alemania, ejecutar un script así para acceder a datos de otras personas es ilegal
  Es como que la puerta de un auto ajeno esté abierta y por eso te metas y lo enciendas
  Para una explicación legal relacionada, ver este artículo

  • Entonces la ley debería cambiar. Ese nivel de indiferencia hacia la seguridad jamás mejorará sin informantes de buena fe o una filtración masiva
  • Yo también estoy de acuerdo. Hay que saber dónde detenerse
    Está bien tomar capturas y reportarlo dentro del uso normal del sitio, pero recolectar datos con un script de Python ya cruza la línea
    Es como ver abierta la puerta de un banco y, en vez de avisarle a la policía, entrar
  • Ojalá que un criminal no explote esa brecha

• El año pasado encontré una vulnerabilidad en el sistema de entradas de un gran evento
  El enlace del ticket recibido por correo era el número de orden secuencial codificado en base64
  Es decir, era fácil descargar también los tickets de otras personas
  Les envié correos tanto a los organizadores como a la empresa desarrolladora, pero no hubo ninguna respuesta, y sigue abierto hasta ahora
  Voy a observar este año durante el evento para ver si lo corrigieron

• Si el ID de usuario era secuencial y la contraseña predeterminada era la misma, la verdadera vulnerabilidad era la “suposición de que existe alguien encargado de seguridad”
  Hoy en día, la “divulgación responsable” al final no es más que darle tiempo a la empresa para contratar abogados