Suplantación de remitentes @hey.com en HEY (Basecamp)

Resumen

HEY, el servicio de correo de Basecamp, permite configurar "cuentas externas": direcciones de otros proveedores desde las que el usuario envía a través de un servidor SMTP propio. El fallo, clasificado como control de acceso inadecuado, tenía dos partes que se encadenaban:

No se comprobaba la propiedad de la dirección. Al dar de alta una cuenta externa, HEY aceptaba que reclamase una dirección @hey.com ajena (por ejemplo, la dirección de soporte de HEY) siempre que las credenciales SMTP funcionasen, aunque fueran de un servidor que no tenía nada que ver con esa dirección.
El envío caía en la infraestructura de HEY si la autorización desaparecía. Los mensajes se encolan y se despachan de forma asíncrona. Si la cuenta externa se borraba entre el encolado y el envío, HEY no cancelaba el mensaje: lo entregaba por sus propios servidores, conservando el remitente reclamado y firmándolo con su DKIM.

El resultado era un correo que aparecía como enviado por "The HEY Team" desde la dirección oficial de soporte de HEY y que superaba SPF, DKIM y DMARC en Gmail e iCloud. El investigador lo reprodujo con autorización del equipo de seguridad de Basecamp, enviando el mensaje solo a buzones suyos y sin acceder en ningún momento al buzón real de soporte.

Pasos de reproducción

El investigador automatizó el ataque con un script en Python. El comando que usó (con contraseñas, servidor y direcciones personales retiradas) fue:

python3 poc.py \
  --attacker [REDACTADO]@hey.com \
  --attacker-password="[REDACTADO]" \
  --spoof [REDACTADO]@hey.com \
  --sender-contact-name "The HEY Team" \
  --subject "The HEY Team authorized PoC" \
  --message "Authorized inert PoC for HEY sender authorization; no action requested." \
  --recipient [REDACTADO] \
  --recipient [REDACTADO] \
  --smtp-host [REDACTADO] \
  --smtp-user [REDACTADO] \
  --smtp-password="[REDACTADO]" \
  --authorization-reference BASECAMP-RETEST-001 \
  --confirm-authorized-scope

Lo que hace el script, en orden:

Inicia sesión con una cuenta de HEY corriente, la del atacante.
Crea una cuenta externa temporal que dice ser la dirección de soporte de HEY, pero con las credenciales de un servidor SMTP propio del atacante, sin relación con HEY.
Encola un mensaje inofensivo usando esa dirección de soporte como remitente y "The HEY Team" como nombre visible.
Borra la cuenta externa temporal antes de que el sistema despache el mensaje (en la prueba, unos 0.797 segundos después del envío).
Comprueba que la cuenta se ha borrado y revoca la sesión temporal.

En ningún paso se usa la contraseña ni el buzón de soporte suplantado.

Qué se observó

Los dos destinatarios recibieron el correo en la bandeja de entrada, con:

From: The HEY Team <[REDACTADO]@hey.com> (la dirección de soporte de HEY)
Subject: The HEY Team authorized PoC
Body: Authorized inert PoC for HEY sender authorization; no action requested.

En el servidor quedó constancia de un único envío y un único borrado, de la eliminación de la cuenta externa temporal y de que no se escribió ni borró nada en el contacto protegido de soporte.

Una segunda prueba, enviando un EML en bruto desde otra cuenta propia del investigador, mostró qué cabeceras salían por esa vía:

La dirección reclamada aparecía tal cual en From y en Return-Path.
No había cabecera Sender ni Reply-To que delatase el origen real.
El mensaje llevaba la firma DKIM de HEY: d=hey.com; s=heymail.
SPF, DKIM y DMARC pasaban, y el correo llegaba a la bandeja de entrada de Gmail e iCloud.

La diferencia estaba en el borrado: si la cuenta externa seguía existiendo, el correo salía por el servidor SMTP configurado (el del atacante); si se borraba antes del despacho, salía por los servidores de HEY con la identidad falsa intacta.

Impacto

Cualquier usuario de HEY podía enviar correo en nombre de otro usuario de HEY o de una identidad de confianza del propio servicio, como su dirección de soporte, sin conocer su contraseña ni tener acceso a su sesión o buzón.

Como era HEY quien firmaba y entregaba el mensaje, los proveedores de los destinatarios lo trataban como correo legítimo de hey.com. Eso rompe la separación entre usuarios a la hora de enviar y permite campañas de phishing muy creíbles haciéndose pasar por el soporte de HEY. Las directrices del programa incluyen la suplantación de correo en su alcance.

HackerOne lo marcó como severidad alta y el programa pagó recompensa, aunque el importe no es público.

Remediación

El reporte no detalla cómo se corrigió. Según el investigador, el comportamiento esperado es doble:

HEY debe rechazar cualquier intento de configurar un remitente @hey.com que no pertenezca a la cuenta autenticada.
Si la autorización del remitente desaparece después de encolar el mensaje, el envío debe cancelarse en lugar de recurrir a la infraestructura de HEY conservando y firmando la identidad no autorizada.

Qué aprender de este caso

Al revisar funciones de "enviar como" o alias de remitente, prueba a reclamar direcciones del propio dominio del servicio: la verificación suele pensarse para dominios externos y olvidar que el dominio de casa es justo el más valioso.
Que unas credenciales SMTP funcionen solo demuestra acceso a ese servidor, no la propiedad de la dirección. La verificación tiene que ser sobre la dirección en sí (un enlace o código enviado a ese buzón).
En colas asíncronas, vuelve a comprobar los permisos al despachar y cancela si el recurso que los justificaba ya no existe. Borrar el objeto entre encolado y envío es una prueba rápida para descubrir rutas de reserva que nadie ha pensado.
Si un servicio firma con DKIM todo lo que sale por sus servidores, cualquier ruta que deje pasar un From arbitrario se convierte en suplantación "autenticada"; la firma solo debe aplicarse a remitentes validados para esa cuenta.