Reports
CRÍTICA[AUTENTICACIÓN]#2718253

Insightly: saltarse la verificación de email en el alta y crear cuentas con correos ajenos, incluso ya registrados

El alta de Insightly confiaba en el parámetro EmailAddress de la petición a /signup/provisionuser. Cambiándolo se creaba una cuenta con un correo ajeno sin verificarlo, incluso uno ya registrado, con riesgo de toma de cuenta.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

El proceso de registro de Insightly (CRM en la nube) se apoyaba en un dato que controla el cliente: el parámetro EmailAddress de la petición que se envía a este endpoint al completar el alta:

https://accounts.insightly.com/signup/provisionuser

El flujo normal consiste en indicar un correo en https://accounts.insightly.com/signup, seguir el enlace que llega a ese buzón y rellenar nombre, apellidos y contraseña. El investigador akostak comprobó que, si se intercepta la petición final y se cambia EmailAddress por otra dirección, el servidor crea la cuenta con esa otra dirección sin haberla verificado y deja la sesión abierta sobre ella.

HackerOne clasificó el fallo como Improper Authorization con severidad crítica. El reporte se envió el 15 de septiembre de 2024, se resolvió y se divulgó el 18 de agosto de 2025. Hubo recompensa, pero el importe no es público.

Pasos de reproducción

Antes de empezar, conviene tener una cuenta de prueba ya creada (o crearla en ese momento) para comprobar el ataque contra cuentas que ya existen.

  1. Ir a https://accounts.insightly.com/signup e introducir un correo controlado por quien hace la prueba.
  2. Seguir el enlace recibido y rellenar los campos de nombre, apellidos y contraseña, pero sin enviar todavía el formulario.
  3. Con un proxy como Burp Suite, interceptar la petición que sale hacia /signup/provisionuser.
  4. Sustituir el valor del parámetro EmailAddress por otro correo. Para probarlo contra una cuenta existente, poner el correo de la cuenta de prueba creada antes.
  5. Dejar pasar la petición. La aplicación redirige automáticamente a la cuenta creada con ese correo, sin pedir ninguna verificación.

Impacto

Según el investigador, afecta a cualquier usuario de Insightly, tenga o no cuenta:

  • Correos sin cuenta: se puede registrar una cuenta a nombre de cualquier dirección sin tener acceso a su buzón.
  • Correos ya registrados: el alta se repite sobre esa dirección. El investigador indica que esto permite tomar el control de la cuenta.
  • Abuso del periodo de prueba: al volver a dar de alta una dirección existente se crea una instancia nueva y vuelven a empezar los 15 días de prueba gratuita, así que la prueba se puede renovar sin límite.

Remediación

El reporte figura como resuelto, pero el texto divulgado no explica qué cambió Insightly.

Qué aprender de este caso

  • En flujos de registro de varios pasos (correo → enlace → formulario final), revisa si la última petición vuelve a enviar el email. Si lo hace, prueba a cambiarlo: es el punto donde el servidor puede olvidar qué dirección se verificó.
  • El correo verificado tiene que salir del lado del servidor, ya sea del token del enlace o de la sesión creada al abrirlo, y no de un campo del formulario. Si provisionuser aceptaba EmailAddress del cliente, la verificación previa no servía de nada.
  • Antes de provisionar una cuenta o una instancia, comprueba si el correo ya existe y rechaza el alta en lugar de rehacerla. Así se evitan la toma de cuentas y la renovación infinita de periodos de prueba.