SpamChannel: enviar correos electrónicos con suplantación desde más de 2 millones de dominios y prácticamente convertirse en Satanás [PDF]

 (media.defcon.org)
1 puntos por GN⁺ 2023-09-24 | 1 comentarios | Compartir por WhatsApp
  • La presentación de DEFCON 31 2023 SpamChannel aborda un problema de suplantación dirigido a más de 2 millones de dominios, a partir de un intento de enviar correo electrónico con Cloudflare Worker
  • El experimento central parte de procesar el envío de correo no de forma manual, sino de manera programática, y conectarlo al flujo de despliegue de Worker
  • Cloudflare Workers se presenta como un entorno de computación sin servidor basado en JavaScript, TypeScript y WASM
  • El procedimiento básico sigue el flujo de crear un proyecto con npm create cloudflare@latest y desplegarlo con npx wrangler deploy
  • La pista para enviar correo desde Workers continúa en la entrada del blog de Cloudflare sobre la integración con MailChannels

Punto de partida de la presentación SpamChannel

  • SpamChannel es un PDF presentado en DEFCON 31 2023 por Marcello Salvati(@byt3bl33d3r) y trata el tema de enviar correos con suplantación desde más de 2 millones de dominios
  • El objetivo de la presentación es implementar el envío de correo bajo las siguientes condiciones
    • Enviar correo de forma programática
    • Enviarlo a través de un Cloudflare Worker
  • Incluye un aviso de exención de responsabilidad relacionado con temas legales que dice “no cometan delitos”

Cloudflare Workers y la pista sobre el envío de correo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-24
Opiniones en Hacker News

  • Video de la presentación: https://www.youtube.com/watch?v=NwnT15q_PS8
    O también está aquí. En mi Firefox el formato de video no funcionó, pero en VLC sí se reproduce: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF está roto de muchas más formas que las cubiertas en esta presentación. Como ingeniero que trabaja en refuerzo de seguridad de email/soporte de entregabilidad, mi consejo siempre es enfocarse en DKIM + DMARC por encima de SPF
    SPF sigue siendo necesario por motivos legacy, pero no hay que depender de él para la entregabilidad ni para prevenir suplantación
    La diapositiva 54 dice que DKIM + DMARC no ayudan contra este ataque, pero no es del todo cierto
    Solo se puede activar de forma segura una política DMARC p=reject cuando se configuró DKIM para todos los remitentes delegados, y al llegar a ese nivel se puede empezar a quitar SPF para remitentes de terceros usando el modificador neutral ? en SPF
    Por ejemplo, v=spf1 include:relay.mailchannels.net ~all pasa a ser v=spf1 ?include:relay.mailchannels.net ~all
    Con esto, el correo proveniente de MailChannels será tratado como neutral en SPF por los receptores compatibles con DMARC y se usará DKIM; los servicios de correo legacy más antiguos también deberían aceptar un resultado neutral
    No es una solución perfecta, pero el email, de todos modos, nunca podrá ser 100% confiable ni seguro

    • Entonces me da curiosidad cuál es el problema de SPF. Como falsificar la IP de origen en TCP es bastante difícil, siempre me pregunté qué ventaja tiene DKIM sobre SPF
      Yo he configurado SPF para permitir solo $myIP. Para enviar spam con mi nombre de dominio, primero tendrían que comprometer a mi ISP o a mi registrador, y a ese nivel también podrían obtener un certificado TLS para mi dominio
      Incluso en organizaciones grandes que tienen que poner varios sistemas de envío en una allowlist, no sé cuál sería la forma de hacerse pasar por uno de los remitentes SPF legítimos cuando no es posible falsificar registros DKIM
      Casos como el de la presentación enviada, donde se pone en la allowlist un rango de IP que cualquiera puede usar públicamente, son simplemente una configuración tonta
      Para falsificar todo el intercambio de correo se necesitaría tráfico del orden de terabytes para un solo email de unos pocos bytes, y si STARTTLS se fuerza, se vuelve imposible

  • Usamos Cloudflare Workers + MailChannels en producción. Da vértigo
    Ya estábamos trabajando en pasar de CF Workers a un servidor real, pero ahora parece que también tendremos que dejar MailChannels
    El riesgo de seguridad no vale la comodidad

    • Desde junio de 2023, no se puede enviar email desde Workers a través de MailChannels si no se publica un registro _mailchannels en DNS
    • Para dejarlo claro, este problema está en que MailChannels no autentica al remitente como propietario verificado del dominio de envío. CF Workers no es el problema

  • “Mostrar un banner en todos los emails que vengan de un dominio que implementó DKIM pero que no tengan firma DKIM” es, según entiendo, mayormente imposible. Porque no hay una forma segura de saber qué dominio implementó DKIM
    En teoría, se podría hacer una consulta DNS a "_domainkey.example.com" y ver si responde NXDOMAIN o NOERROR. Lo segundo normalmente significa que hay subdominios y, por lo tanto, podría implicar que existen algunas claves DKIM en DNS
    Pero no se puede saber el nombre del selector, ni si esa clave está activa o si se piensa activar más adelante
    Un dominio puede tener varios remitentes autenticados, y algunos pueden usar firmas DKIM mientras otros no
    No todos los servidores DNS siguen bien el estándar, así que la distinción NXDOMAIN/NOERROR también funciona solo de manera aproximada

    • Si un proveedor ve una proporción estadísticamente significativa del tráfico de correo, puede ver todos o casi todos los selectores DKIM
      La frase citada parece querer decir que se rechacen los correos provenientes de MailChannels que no tengan firma DKIM

  • “Los principales clientes de MailChannels son proveedores de web hosting que no son dueños de los dominios de los emails que envían” es una de las excusas más flojas que he oído en mucho tiempo
    Los proveedores de web hosting normalmente no “poseen” los dominios que alojan, pero sí saben perfectamente qué dominios alojan. Enrutar un dominio a una cuenta/directorio de cliente es el núcleo del web hosting
    Lo único necesario es una integración tipo cPanel que reporte la lista de dominios y vincule cada dominio a una clave generada aleatoriamente
    Todo esto puede y debe automatizarse sin molestar al usuario final

    • ¿Y qué pasa con las listas de correo? ¿Y con el reenvío de correo?

  • Ojalá la especificación DMARC evolucione para que haya una forma de usar solo DKIM, y no SPF, para la verificación. Lamentablemente, cosas como las invitaciones de Google Calendar todavía fallan con DKIM

    • Es muy probable que la próxima versión de DMARC incluya una opción para excluir SPF de la verificación DMARC. El equipo de Google la está impulsando en la lista de correo de DMARC del IETF:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Me parece una muy buena idea, porque permite que el dueño de un dominio use DMARC y, aun así, especifique: “quiero que el único mecanismo que autentique realmente el tráfico de mi dominio sea DKIM”
      En la industria hay muchas formas de eludir las debilidades de SPF y DMARC, como las macros de SPF, que ajustan dinámicamente la autenticación con criterios que solo se conocen al momento de evaluar SPF
      Pero ninguna solución alternativa es mejor que decir: “para mi dominio, usen solo DKIM”

  • Hace poco pasé por el proceso de preparar el correo de mi propio dominio, y fue increíblemente frustrante, sobre todo por los ISP que deciden que “para enviar correo desde tu propio equipo necesitas una cuenta empresarial”; este tipo de cosas de verdad me enfurecen
    Me esfuerzo muchísimo por ser un miembro responsable de la red, e investigué y desarmé todo hasta el estado más actual para configurar bien mis sistemas
    Y aun así existen personas así que, además, operan prácticamente como open relays con total ligereza, y casi la mitad de Internet termina pagando el precio. Es absurdo

  • En resumen, se trata de que encontraron open relays incluidos en muchos registros SPF

    • De los 2 millones de dominios que se dejaron abiertos mediante registros SPF, menos de 1,000 habían configurado registros DKIM/DMARC, e incluso cuando DKIM estaba configurado y abandonado, Gmail todavía lo aceptaba como autenticado
    • Es peor que eso. La propia plataforma ni siquiera intentaba hacer verificación de propiedad del dominio, así que se podía enviar en nombre de cualquiera
    • Estrictamente hablando, no es un open relay. MailChannels no habría podido existir en Internet si no controlara agresivamente el spam y el phishing
      La charla de DEFCON no demostró la existencia de un agujero enorme, sino que mostró algo que ha sido cierto desde los inicios del correo electrónico en Internet
      Si no se usan firmas de mensajes como S/MIME o DKIM, no se puede autenticar suficientemente el dominio del remitente
      Incluso con DKIM, es posible un abuso generalizado mediante ataques de reenvío DKIM

  • Es interesante el impacto que tienen los encabezados ARC en la puntuación de spam. Como alguien que opera un servidor de correo personal, ¿podría mejorar la entregabilidad simplemente agregando a mis correos un conjunto de encabezados ARC sin sentido?

    • Quisiera decir que no. Si eso fuera cierto, creo que todas mis bandejas de entrada repartidas entre varios proveedores estarían inundadas de spam
      Los spammers organizados y con conocimientos seguramente investigan a fondo todo este tipo de cosas, y es casi seguro que las usan para abrirse paso
    • En la industria del correo electrónico no se considera que ARC sea una forma perfecta de eludir los filtros de spam de los grandes receptores. Al ponente de DEFCON le faltaba preparación para emitir ese juicio

  • Parece que esto ya se había confirmado en mayo de 2022: https://news.ycombinator.com/item?id=30533032

    • Al parecer, el CEO dijo algo así:
      “Tenemos amplias capacidades de detección de spam y phishing, y podemos manejar los abusos”
      Ah, claro :D