- En un análisis de los 1 millón de sitios web más importantes se encontraron más de 1,700 claves públicas DKIM de menos de 1,024 bits, y el experimento verificó si la clave RSA DKIM de 512 bits de redfin.com podía explotarse en la práctica
- Al decodificar la etiqueta
pdel registro DKIM se obtuvieron el módulo RSAny el exponente públicoe=65537, tras lo cual se factorizó el módulo con CADO-NFS - En un servidor de Hetzner con 8 vCPU dedicadas y 32 GB de RAM,
nse dividió en los dos primospyqen unas 86 horas, y con eso se reconstruyó la clave privada RSA - Al firmar correos enviados desde
security@redfin.comcon la clave privada reconstruida, Gmail y Outlook los rechazaron, pero Yahoo Mail, Mailfence y Tuta devolvierondkim=pass - Bajo la política DMARC de redfin.com,
p=reject; pct=100, pasar DKIM implicó pasar DMARC, por lo que los proveedores de correo deberían rechazar firmas DKIM RSA de menos de 1,024 bits
El problema de que aún existan claves DKIM de 512 bits
- En un estudio de registros SPF, DKIM y DMARC de los 1 millón de sitios web más importantes se encontraron más de 1,700 claves DKIM públicas con longitud inferior a 1,024 bits
- Las claves RSA de menos de 1,024 bits se consideran inseguras, y en DKIM su uso está en estado de obsolescencia recomendada desde RFC 8301 en 2018
- El objetivo del experimento fue la clave pública RSA de 512 bits encontrada en
key1._domainkey.redfin.com - La meta era comprobar si, usando solo la clave pública, era posible restaurar la clave privada y firmar correos como si provinieran del dominio original
- También se verificó si grandes proveedores de correo como Gmail, Outlook.com y Yahoo Mail aceptaban firmas DKIM hechas con claves cortas
Extracción de componentes RSA desde la clave pública DKIM
- La etiqueta
pdel registro DKIM contiene la clave pública codificada en formato ASN.1 DER y luego recodificada en Base64 - Se leyó la clave pública con
Crypto.PublicKey.RSA.import_keyde Python para extraer los componentes RSA- Módulo
n:10709580243955269690347257968368575486652256021267387585731784527165077094358215924099792804326677548390607229176966588251215467367272433485332943072098119 - Exponente público
e:65537
- Módulo
Factorización del módulo con CADO-NFS
- Para crear la clave privada RSA hay que descomponer el módulo
nen el producto de dos primospyq - Para la factorización se usó CADO-NFS
- CADO-NFS es una implementación del algoritmo Number Field Sieve (NFS), usado para factorizar enteros grandes
- Se alquiló un servidor en la nube de Hetzner para no ocupar una computadora local durante varios días
- Las especificaciones del servidor eran 8 vCPU dedicadas, AMD EPYC serie 7003 y 32 GB de RAM
- El sistema operativo era Ubuntu
- Se añadieron 32 GB de swap para asegurar memoria suficiente para el trabajo
- Se ejecutó la factorización ingresando el módulo
nencado-nfs.py - El proceso completo tomó unas 86 horas en el servidor de 8 vCPU, y
nse descompuso en los siguientes dos primosp = 97850895333751392558280999318309697780438485965134147739065017624372104720767q = 109447953515671602102748820944693252789237215829169932130613751100276125683257
- Con un servidor más potente o una ejecución distribuida en varios sistemas, el tiempo podría reducirse, y CADO-NFS simplifica el trabajo distribuido
Reconstrucción de la clave privada RSA
- Tras obtener
p,qye, se construyó la clave privada RSA con Python y PyCryptodome - En el cálculo se usaron los siguientes valores y pasos
n = p * qphi = (p-1) * (q-1)d = inverse(e, phi)RSA.construct((n, e, d, p, q))
- El resultado fue una clave privada RSA en formato PEM, que se integró en la configuración de OpenDKIM y se usó para firmar correos de prueba
Resultados de validación DKIM por proveedor de correo
- La clave privada reconstruida se cargó en OpenDKIM y se enviaron correos de prueba con la dirección FROM
security@redfin.coma varios servicios de hosting de correo - La mayoría de los proveedores consideró insegura la clave de 512 bits y rechazó la firma DKIM, pero tres devolvieron
dkim=pass - Los resultados por proveedor fueron los siguientes
- Gmail: FAIL
- Outlook: FAIL
- Yahoo Mail: PASS
- Zoho: FAIL
- Fastmail: FAIL
- Proton Mail: FAIL
- Mailfence: PASS
- Tuta: PASS
- GMX: FAIL
- OnMail: FAIL
- redfin.com tiene un registro DMARC válido con formato
v=DMARC1;p=reject;pct=100;... - Para redfin.com, pasar la validación DKIM llevó a pasar también la validación DMARC, y además se cumplieron los requisitos de BIMI
Costos y medidas operativas
- Hace 30 años, romper una clave pública RSA de 512 bits era una tarea de nivel supercomputadora, pero hoy puede hacerse en un servidor en la nube por menos de US$8
- Si se cuenta con una computadora doméstica potente de 16 núcleos o más, podría hacerse más rápido y más barato
- No hay razón para mantener claves DKIM de 512 o 768 bits, y los proveedores de correo deberían rechazar automáticamente firmas DKIM generadas con claves RSA de menos de 1,024 bits
- Los resultados del experimento y la recomendación se compartieron con Yahoo, Mailfence y Tuta
- Los propietarios de dominios deberían revisar registros DKIM antiguos en su configuración DNS
- La etiqueta
pdel registro DKIM puede comprobarse fácilmente contando los caracteres Base64 - Una clave pública RSA de 1,024 bits tiene al menos 216 caracteres en Base64
- La etiqueta
1 comentarios
Opiniones de Hacker News
Hace 14 años ya era posible romper claves RSA DKIM de 512 bits: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b...
La lógica era que, con claves cortas, las firmas DKIM no quedaban como prueba por mucho tiempo, lo que permitía preservar la negabilidad, dificultando demostrar más adelante qué correo había sido auténtico
Claro que eso no significa que la mayoría de las empresas usaran claves cortas por esa razón, sino que existía la idea de que las claves cortas no eran del todo malas
La negabilidad en DKIM es un tema que personalmente llevo mucho tiempo siguiendo [1]; estas claves cortas claramente no son una solución, pero las veo como resultado del pensamiento confuso alrededor de DKIM y de una comunidad que no quería aceptar las implicaciones de todos los sistemas de firma de correo electrónico
[1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
https://www.wired.com/2012/10/dkim-vulnerability-widespread/
En términos generales, en unos 14 años se pasó de unas semanas a 8 horas
Si quieren probarlo por diversión, pueden crear una clave DKIM de 4096 bits
Los verificadores DKIM/SPF en línea dirán que todo está bien si solo miran DNS, pero el correo de prueba fallará
Muestran una explicación excelente, algo como
STATUS: Fail,DKIM: Pass,SPF: PassUsar una clave de más de 2048 bits en un registro DKIM está permitido y es válido, pero los validadores no estaban obligados a manejar claves de más de 2048 bits
Perdí algo de cabello aprendiendo esto en carne propia
Curiosamente, los sitios dicen que los tres registros son correctos y válidos, pero aun así tratan el correo como fallido
Probablemente sea porque la verificación de registros DNS y la validación del correo electrónico las maneja software distinto
Los verificadores deben poder validar firmas con claves de entre 512 y 2048 bits, y se indica que también pueden verificar claves más grandes
Hace un año escribí mi tesis de maestría sobre este tema, y hoy los principales proveedores de correo soportan todos 4096 bits; algunos incluso soportaban hasta 16384 bits
Me pregunto por qué no se aumenta de forma generalizada el tamaño de las claves en toda la criptografía
Aunque no sea una solución definitiva, parece que serviría para ganar tiempo
La capacidad de cómputo crece rápido y se sigue hablando de computadoras cuánticas, pero da la impresión de que todos se quedan quietos
Claro que las claves más grandes tienen mayor costo computacional, pero también tenemos más recursos de cómputo, así que quizá deberíamos usarlos para defendernos, no solo para atacar
Incluso algo simple como forzar TLS 1.3 en el cliente en vez de TLS 1.2 rompe muchas cosas, incluido el sitio de HN
Esos números no tienen que ver con el nivel tecnológico de los dispositivos, sino con los máximos permitidos por la termodinámica
En conclusión, romper AES-256 o RSA-4096 por fuerza bruta es físicamente imposible
Las claves de 1024 bits llevan más de una década siendo retiradas en muchos sistemas criptográficos
Salvo alguna excepción rezagada, las únicas amenazas para claves de 2048 bits son las computadoras cuánticas, y eso amenaza a RSA en sí
El progreso no es lineal, así que el hecho de que 1024 se haya debilitado no significa que 2048 vaya a caer mecánicamente pronto; incluso 1024 hoy no es fácil de atacar en la práctica
DKIM es una de las excepciones
En el mundo DKIM se está esperando una adopción amplia de Ed25519, y eso resolvería varias molestias
Por lo general, ese dolor se traslada directamente al usuario, no al operador del servicio, y el modelo es esperar que los usuarios se quejen lo suficiente como para que el operador preste atención
Pero también es muy probable que los usuarios se vayan con un competidor que no deje que un detalle menor como la seguridad bloquee las ventas
En la práctica, es como preguntar “por qué no hacemos lo que ya estamos haciendo”
Con CADO-NFS se puede hacer de forma sorprendentemente fácil
Hace unas semanas, por trabajo, factoricé una clave RSA DKIM de 512 bits con una computadora de escritorio y solo tardó 28 horas
Concretamente, era un AMD Zen 5 9900X
Lamentablemente, las claves de 1024 bits aún están fuera del alcance de un esfuerzo de aficionado, pero podrían ser posibles para un proyecto académico de una escala similar al que factorizó una clave de 768 bits en 2010: https://eprint.iacr.org/2010/006.pdf
Ayer recibí un correo de Bank of America sobre un problema con la configuración de la cuenta.
Sí había creado una cuenta nueva, y el correo sabía ese hecho, el nombre de la empresa, etc.
No tenía enlaces; solo indicaba llamar al número comercial de BofA, y al verificar el número en el sitio web de BofA era el mismo, así que llamé.
Pero nadie pudo decirme por qué había recibido el correo ni qué problema había con la cuenta, y el agente tampoco pudo encontrar registro de que se hubiera enviado ese correo.
Estoy 100% seguro de que ese correo vino de Bank of America.
No tenía elementos de phishing, ni enlaces, ni números telefónicos maliciosos.
SPF, DKIM y DMARC pasaron todos en los ARC-Authentication-Results de Google, y la clave DKIM también era de 2048 bits.
Le pedí a Bank of America que lo investigara y me respondieron que “probablemente era un mensaje de phishing”, enviándome un enlace con consejos para evitar el phishing.
Lo más probable es que haya sido un simple error: algún sistema ejecutó una verificación de consistencia demasiado pronto durante la creación de la cuenta y generó el correo.
Pero como ellos dijeron que era “phishing”, envié por FedEx todo el material adjunto al CTO.
Es una de dos: o se filtró la clave DKIM y deben emitir una alerta pública de inmediato, o empleados y sistemas de TI incompetentes me hicieron dar vueltas y perder una hora.
En cualquiera de los dos casos, quiero una investigación completa y una solución.
Algunos proveedores de DNS son pésimos y solo permiten configurar claves de hasta 1024 bits de longitud.
Por ejemplo, wordpress.com es así.
Como referencia, el último número RSA roto fue RSA-250, es decir, 829 bits, y en 2020 tomó 2700 años-núcleo [1].
En cambio, RSA-155, es decir, 512 bits, ya había sido factorizado en 1999.
No es una situación peligrosa.
[1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
La razón es que no ofrece un nivel de seguridad suficiente.
No alcanza para detener a la NSA, pero considerando que DKIM es una de varias capas de protección, parece suficiente para frenar a los spammers.
Me pregunto si hay un límite en el tamaño de los registros TXT, o si intentan parsear a propósito los registros TXT que parecen DKIM, fallan y rechazan agregarlos.
Romper una clave de 512 bits para una buena demostración es investigación de seguridad muy valiosa, aunque ya se haya hecho antes.
También es legítimo publicar “aquí hay una lista de sitios que todavía usan 512 bits, así que deben migrar”.
Pero romper directamente una clave real en operación me resulta incómodo; personalmente siento que cruza una línea ética.
No soy abogado, pero parece que incluso podría ser delito, y se ve algo innecesario.
Basta con buscar
now no longer availableen el texto original.Normalmente, cuando se demuestra que un sistema en línea es vulnerable, se reproduce la vulnerabilidad de buena fe, se documenta la investigación y se solicita revisión.
El proceso es el mismo tanto si se trata de romper un sistema criptográfico, obtener ejecución de código arbitrario en una consola de videojuegos bloqueada, demostrar que se pueden manipular datos de una máquina de votación o mostrar que se pueden modificar comentarios de Q&A en Google Meet.
Si solo dices que algo es vulnerable, pueden ignorarte; si dices que es vulnerable y lo pruebas, se vuelve difícil ignorarlo.
Y si a eso le sumas un plazo de divulgación estándar de la industria, diciendo que intentaste contactarlos durante unos 60 días y luego publicarás la vulnerabilidad, prácticamente no queda margen para ignorarlo.
Es simplemente matemáticas.
Lo ilegal es usar esas matemáticas para enviar correos fraudulentos o que violen leyes de una jurisdicción específica.
Lo central no son las matemáticas, sino la acción y la intención.
Señalar que alguien está haciendo algo tonto tampoco es ilegal, aunque sí pueden intentar hacerte la vida difícil.
Algo como: “está bien mostrar que un bug es explotable, pero escribir código de prueba de concepto cruza la línea”.
El problema es que, si no muestras que realmente es posible, la mayoría no escucha la investigación de seguridad.
En cambio, de los 10 principales proveedores de correo que no seguían correctamente el RFC de DKIM, se divulgaron 3 tras notificarlos: Yahoo, Tuta y Mailfence.
Esta fue la razón por la que tuve que dejar de administrar DNS con Hover.
No admite registros TXT de más de 255 caracteres, y tampoco encontré casos en los que los registros divididos funcionaran en Hover.
Al final terminé usando Digital Ocean.
Si este problema va a seguir otros 10 años, ojalá la criptografía de curva elíptica se vuelva el estándar.
En la parte que dice: “la mayoría de los proveedores identificaron correctamente las claves de 512 bits como inseguras y rechazaron la firma DKIM, pero tres proveedores importantes — Yahoo Mail, Mailfence, Tuta — reportaron dkim=pass”, me pregunto si Google realmente falló porque la firma DKIM era insegura o si falló por el fallo de SPF.
dkim=policy (weak key).Es exactamente el requisito de que “los verificadores no deben considerar como firma válida una firma que use una clave RSA de menos de 1024 bits”.
Que 512 bits sea un número grande o pequeño depende de si se trata de criptografía simétrica o criptografía asimétrica
Se puede asumir que la criptografía asimétrica siempre es 8 veces más débil que la simétrica
DKIM usa un esquema asimétrico, así que DKIM de 512 bits equivale a 64 bits en términos de hash simétrico, un nivel que ya fue roto hace mucho
Incluso SHA-1 de 160 bits se considera roto
Si se quisiera un DKIM con una fortaleza similar a SHA-3 de 512 bits, se necesitarían al menos 4096 bits, y aun así eso no incluiría las técnicas de mitigación contra ataques de retransmisión de SHA-3
Es un estándar que coloca una firma en los encabezados del correo electrónico y la verifica
Lamentablemente, DKIM solo admite firmas
rsa-sha1yrsa-sha256: https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3Sería bueno que DKIM se revisara para permitir Ed25519 o firmas similares
Por ejemplo, ECC de 224 bits es aproximadamente similar a RSA de 2048 bits
Ambos son esquemas asimétricos
En cambio, la curva elíptica asimétrica tiene una fortaleza similar a la de AES, que es un cifrado simétrico
Por supuesto, es vulnerable a las computadoras cuánticas