Trellix Healthwatch: registro con cualquier email, activación sin aprobación y API que expone clientes y correos internos

Resumen

El investigador t4f3 encadenó tres fallos en healthwatch.trellix.com, una aplicación web de Trellix:

1. El dominio del email no se validaba en el servidor. El registro exigía una dirección del dominio de la empresa, pero la petición que llegaba al servidor podía llevar cualquier otra.
2. La recuperación de contraseña activaba cuentas pendientes. Las cuentas nuevas quedaban a la espera de que un administrador las aprobara, pero el flujo de "Olvidé mi contraseña" permitía fijar una contraseña e iniciar sesión sin esa aprobación.
3. Un endpoint de la API no comprobaba permisos. Con esa cuenta de bajo privilegio, /api/ApiV1/GetCustomerDetailByEmail devolvía los nombres de todas las empresas cliente y los correos de los empleados que habían creado cada cuenta.

HackerOne lo clasifica como Improper Access Control - Generic (CWE-284), con severidad media. El reporte se envió el 9 de noviembre de 2025, figura como resuelto y se divulgó el 8 de noviembre de 2026.

Pasos de reproducción

Fase 1: registrar una cuenta con un dominio externo

1. Abrir la página de registro de la aplicación.
2. Rellenar el formulario con una dirección que termine en el dominio de la empresa (@trellix.com).
3. Interceptar la petición de registro con un proxy como Burp Suite.
4. Cambiar en la petición el email por uno de un dominio cualquiera (en el reporte, un buzón temporal de yopmail.com).
5. Reenviar la petición modificada. El registro se acepta y la cuenta queda creada, pendiente de aprobación por un administrador.

Fase 2: activar la cuenta sin aprobación

1. Sin haber fijado contraseña en el registro, ir a la página de "Olvidé mi contraseña".
2. Solicitar el restablecimiento para el email externo registrado.
3. Abrir el correo de restablecimiento que llega a esa dirección externa.
4. Completar el proceso de restablecimiento.
5. Iniciar sesión: se accede al panel de la aplicación aunque ningún administrador haya aprobado la cuenta.

Fase 3: enumerar clientes y empleados

1. Con la sesión de la cuenta anterior, enviar peticiones a:

/api/ApiV1/GetCustomerDetailByEmail

1. La respuesta incluye la lista completa de nombres de empresas cliente, los correos internos de los empleados que crearon esas cuentas y metadatos de la relación con cada cliente.

El investigador comprobó por fuentes abiertas (LinkedIn) que los correos expuestos pertenecían a empleados reales.

Impacto

• Acceso no autorizado: cualquiera, sin relación con la empresa, podía obtener una cuenta válida y saltarse el paso de aprobación por un administrador.
• Exposición de la cartera de clientes: listado completo de las empresas cliente.
• Exposición de correos internos: direcciones de empleados de Trellix y su relación con cada cliente.
• Base para ataques dirigidos: con esa relación entre empleados y clientes, un atacante podía preparar campañas de phishing dirigido o fraude del tipo Business Email Compromise muy creíbles, haciéndose pasar por el empleado ante el cliente.

Remediación

El reporte figura como resuelto, pero no explica qué cambió Trellix. Las medidas que propuso el investigador fueron:

• Validar el dominio del email en el servidor, contra una lista de dominios permitidos, y verificar el correo antes de activar la cuenta.
• Mantener la aprobación del administrador incluso después de un restablecimiento de contraseña: impedirlo en cuentas pendientes y comprobar el estado de la cuenta en el middleware de autenticación.
• Desactivar /api/ApiV1/GetCustomerDetailByEmail hasta protegerlo, añadir control de acceso por roles a todos los endpoints, filtrar los datos según los permisos del usuario y limitar el número de peticiones para evitar la descarga masiva.
• Revisar las cuentas pendientes y eliminar las registradas sin autorización.

Qué aprender de este caso

• Si un registro restringe el dominio del email (por ejemplo, "solo @empresa.com"), rellena el formulario con un dominio válido y cambia el email en la petición interceptada: muchas veces la comprobación vive solo en el navegador.
• Revisa los flujos secundarios que también fijan contraseña o crean sesión, como "Olvidé mi contraseña", invitaciones o enlaces mágicos: deben comprobar el estado de la cuenta (pendiente, bloqueada, sin verificar) igual que el inicio de sesión normal, o se convierten en una puerta trasera a la aprobación manual.
• Una vez dentro con la cuenta de menor privilegio, prueba los endpoints que devuelven datos "por email" o "por cliente": es habitual que solo exijan sesión iniciada y no filtren por lo que ese usuario puede ver.
• Al diseñar un flujo con aprobación manual, haz que el servidor no emita sesión ni tokens de restablecimiento a cuentas sin aprobar, en lugar de confiar en que el usuario todavía no tenga contraseña.