No, el 61% de los dominios ".es" no es vulnerable a la estafa del CEO

Kuko Armas <kuko@canarytek.com>
|

No, el 61% de los dominios “.es” no son vulnerables a “la estafa del CEO”, o al menos no podemos sacar esa conclusión en base al análisis presentado en las jornadas STIC de CCN-CERT

Antecedentes

Hace unos días, concretamente el Jueves 13 de Diciembre de 2018, se presentó en las Jornadas Técnicas de CCN-CERT un estudio sobre la supuesta vulnerabilidad de los dominios “.es” a “la estafa del CEO”.

Los resultados presentados han generado cierto revuelo y alarma y ha salido publicado en varios medios, por ejemplo, en La Razón y en COPE

Cuando vi esa presentación me quede algo perplejo por las “atrevidas” conclusiones que se obtenían con una prueba tan simple, y considero que en absoluto se pueden sacar esas conclusiones con las pruebas realizadas. Me da la impresión de que las pruebas realizadas se diseñaron con una visión excesivamente simplificada del funcionamiento del correo electrónico.

A continuación paso a argumentar mi punto de vista.

La estafa del CEO

La estafa en cuestión, consiste en que un “atacante” envía un correo falso al responsable de pagos de una empresa, haciéndose pasar por el directivo de la empresa, y solicitando un pago a una cuenta, o el cambio del número de cuenta al que hay que hacer un pago.

Por lo tanto, para que este “ataque” tenga éxito se tienen que cumplir dos condiciones:

  1. Que el atacante pueda falsear el mensaje de correo, y este mensaje “falso” lo reciba la “victima”
  2. Que la victima “se trague” el engaño y ordene el pago

El estudio mencionado, trata de analizar el primer punto, es decir, determinar que dominios “.es” entregan al usuario final un mensaje con dirección de origen falsa (la del directivo que supuestamente da la orden del pago)

La “estafa del CEO” es un ataque de “ingeniería social”, es decir, se trata de engañar a alguien. El principal problema es el desconocimiento que tienen los usuarios sobre el correo electrónico, a todos los usuarios deberíamos dejarles claro que el correo electrónico es casi como una postal

  • No hay garantía de entrega. No hay una forma infalible de saber si un usuario ha recibido y leído un correo o no (al menos sin recurrir a “trucos” basados en otros servicios)
  • No hay garantía de que el mensaje no ha sido manipulado en tránsito
  • No hay privacidad, cualquiera que tenga acceso a un servidor de correo (o red) de tránsito, puede leer (y modificar) el contenido
  • No hay ninguna garantía de que la dirección de origen mostrada por el programa de correo sea auténtica
  • Ni siquiera hay garantía de que la dirección de entrega que muestra el programa de correo sea correcta. Esta es la que mas le cuesta entender a los usuarios, así que lo aclaro: si, te puedo enviar un correo y que en el destinatario veas shon@prayforshon.org y se te entrega a ti

Es decir, la mejor forma de combatir “la estafa del CEO” y cualquier otro phishing es que el usuario interiorice esto: un mensaje de correo electrónico es igual de seguro que una postal. ¿A que nadie ordenaría un pago por una orden recibida de su jefe en una postal? Pues eso…

El estudio

La lógica tras el estudio presentado es la siguiente: “vamos a comprobar qué dominios aceptarían un correo sin autenticar en el que ponemos como remitente a una dirección de dicho dominio”.

Para entender el estudio (y uno de sus errores de planteamiento) hay que hacer una breve aclaración de como funciona una transacción de correo electrónico. A continuación hacemos una breve descripción de una transacción básica entre los servidores emisor (A) y receptor (B)

A: (abre conexion al puerto 25 del host B) <- A abre la conexion al servicio de correo de B
B: 220 zimbra.modularit.net ESMTP Postfix  <- B se identifica con su nombre
A: HELO evil.superhackers.org              <- A se identifica con HELO (los servidores SMTP son muy educados)
B: 250 zimbra.modularit.net                <- B responde con su nombre
A: MAIL FROM: shon@prayforshon.org         <- A indica que va a enviar un correo con remitente shon@prayforshon.org
250 2.1.0 Ok                               <- B indica que correcto
RCPT TO: kuko@canarytek.com                <- A indica que el correo va destinado a kuko@canarytek.com
250 2.1.5 Ok                               <- B indica que correcto
DATA                                       <- A envia el comando DATA, mas detalles mas abajo
354 End data with <CR><LF>.<CR><LF>        <- B indica que correcto, que para terminar enviemos una linea con un unico punto (.)
From: kuko@canarytek.com
To: shon@prayforshon.org
Subject: test

un test
.
250 2.0.0 Ok: queued as C697D12005A       <- B acepta el correo y nos indica el identificador de cola que se le ha asignado al mensaje

Como puede observarse arriba, el contenido del mensaje se envía tras el comando DATA. En un mensaje de correo electrónico hay dos partes:

  • Cabeceras: son campos de control, la mayoría no las muestra el cliente de correo
  • Cuerpo: es el contenido del mensaje

En el comando DATA, se separan las cabeceras del cuerpo, con una linea vacía.

En el ejemplo anterior, en la transacción SMTP el remitente es shon@prayforshon.org y el destinatario es kuko@canarytek.com, por lo que el mensaje se entregara al buzón de kuko@canarytek.com, pero obsérvese que en el contenido del DATA lo hemos puesto al reves: From: kuko@canarytek.com y To: shon@prayforshon.org. ¿Como se le mostrará el mensaje al usuario en su cliente de correo? pues como se indica en el DATA:

From: kuko@canarytek.com
To: shon@prayforshon.org

Aquí se hace evidente otro de los grandes problemas del correo electrónico: los clientes de correo no nos muestran toda la información relevante para detectar si nos están engañando. Los técnicos podemos irnos a ver todas las cabeceras y analizarlas, pero la mayoría de los usuarios no sabe hacerlo. Los clientes de correo (MUA) deberían, como mínimo, mostrar también las direcciones utilizadas en la transacción SMTP (lo que en terminología de email se denomina “envelope address”)

Tras esta breve descripción, pasamos a describir la metodología usada por el test realizado sobre los “.es”:

  • Se conecta a un servidor de correo
  • Se identifica en el HELO con el nombre del mismo servidor al que se ha conectado (por cierto, esta parte es totalmente irrelevante)
  • Se envia un MAIL FROM: con una dirección del propio dominio que se está probando
  • Se envia un RCPT TO: con una dirección del dominio que se está probando
  • Se cierra la conexión antes del DATA para evitar enviar realmente correos fraudulentos, se conforma con saber si hasta aquí se ha aceptado

Tras ese test, la conclusión del estudio es que si se responde OK a esos tres comandos SMTP, el servidor es vulnerable porque acepta correo con el origen falseado al dominio de destino.

El problema es que esa conclusión es absolutamente falsa, el dominio sera “vulnerable” en todo caso si dicho mensaje termina entregándose al destinatario sin ni siquiera marcarlo como SPAM. Pero asumir que si se ha llegado hasta aquí, el correo será entregado al destinatario es una conclusión precipitada por las siguientes razones:

  • La mayoría de los servidores de correo realizan las verificaciones “pesadas” una vez que el correo se ha aceptado y está en la cola. Es decir, el hecho de que el correo se ha encolado, no implica que no se descarte o se marque como SPAM, ya que habitualmente el correo pasara por filtros Antivirus y AntiSPAM. Algunas de las comprobaciones que suelen realizarse a posteriori son las que se mencionan en la propia charla (SPF, DKIM y DMARC)
  • En los pocos sistemas de correo que realizan comprobaciones “pesadas” durante la transacción SMTP, las hacen una vez recibido el mensaje en el DATA, ya que donde más información se tiene es cuando se recibe el propio mensaje. Un servidor que realizara verificaciones en este punto podría decidir no encolar el correo. El problema es que el test realizado no llega a enviar nada, por lo que se esta verificando una ínfima parte de los sistemas de filtrado de los servidores de correo

Por todo lo descrito, el test realizado tiene una probabilidad altísima de producir tanto falsos positivos como falsos negativos

Falsos positivos

Un falso positivo seria aquel en el que se acepta el correo en el MAIL FROM y RCPT TO, pero se descarta más adelante. Espero que por lo comentado en el apartado anterior sea evidente que esto puede pasar en una cantidad enorme de casos. Por ejemplo, cualquier servidor que aplique correctamente DMARC y DKIM, que son la mejor defensa para este tipo de ataques descartara el mensaje por no contener firma DKIM. Incluso el SPF, que ya podría aplicarse en el momento del MAIL FROM, suele aplicarse más tarde.

Aquí se puede argumentar que aunque se descartara más adelante también debería hacerse aquí, por tener varias lineas de defensa (defensa en profundidad), pero en ese caso se esta obviando infinidad de casos complejos en los que aplicar “lógica de filtrado” en esta fase (con tan pocos datos) es inviable. Por ejemplo:

  • Servidores MX secundarios que suelen tener menos información fidedigna que los destinos finales
  • Entrega de MX secundarios a MX principales (habría que mantener una lista de ip de MX secundarios “autorizados”)
  • Entornos con gran cantidad de dominios distribuidos en gran cantidad de servidores. etc

Pero la razón más importante para no tomar esa decisión en la transacción es la seguridad Si, eso que tratamos de mejorar. Me explico: Si el código que está escuchando y aceptando datos del exterior tiene que hacer muchísimas comprobaciones, será necesariamente más complejo y mas fácil de atacar. La tendencia es disminuir la superficie de ataque haciendo que los servicios “expuestos” sean lo más sencillos posibles (principio de simplicidad).

Precisamente por eso hace muchos años se dejo de usar un sistema “monolítico” como sendmail y se empezaron a usar sistemas “modulares” como postfix, exim, etc. Los que tengan suficiente edad recordarán el infierno de exploits de sendmail. O podemos remitirnos a un clásico

Falsos negativos (mas grave: falsa sensación de seguridad)

En este test, un negativo sería aquel en el que el servidor no nos acepta una dirección del dominio de destino en el MAIL FROM.

Pero realmente lo que queremos evaluar es si podemos “engañar” al usuario haciéndole creer que el correo proviene de su “jefe”. Así que hay que preguntarse: ¿Si el servidor no nos acepta en MAIL FROM con el dominio de destino, aún así podemos engañar a la “victima”? Porque eso sería un falso negativo

Pues resulta que la respuesta puede ser que SI. De hecho, lo que pase con la dirección del MAIL FROM es prácticamente irrelevante, porque el atacante puede hacer que se muestre otra dirección remitente indicándola con la cabecera From:

Siguiendo el ejemplo de transacción de arriba, si quisiera engañar al usuario kuko@canarytek.com haciendole haciéndole creer que soy eljefe@canarytek.com, podría hacer algo tan simple como esto:

A: (abre conexion al puerto 25 del host B)
B: 220 zimbra.modularit.net ESMTP Postfix
A: HELO evil.superhackers.org           
B: 250 zimbra.modularit.net            
A: MAIL FROM: shon@prayforshon.org    
250 2.1.0 Ok                         
RCPT TO: kuko@canarytek.com          
250 2.1.5 Ok                         
DATA                                
354 End data with <CR><LF>.<CR><LF> 
From: eljefe@canarytek.com
To: kuko@canarytek.com
Subject: Ojo que soy el jefe

Enseñame la paaaastaaaa!!!
.
250 2.0.0 Ok: queued as C697D12005A

En esa transacción no he puesto en el MAIL FROM una dirección del dominio de destino, puedo poner cualquier cosa (aunque no exista). Incluso en los pocos casos en los que se hace una verificación de existencia de la dirección remitente, cosa que casi nadie hace porque tiene efectos secundarios “peligrosos”, se puede poner una dirección válida de otro dominio.

Pero a pesar de no poner la dirección “falsa” en la transacción, la indico en el contenido del mensaje (cabecera From:). ¿Que mostrara el cliente de correo?, esto:

From: eljefe@canarytek.com
To: kuko@canarytek.com

Es decir, que sigo pudiendo engañar a la victima.

O sea, que tenemos un falso negativo, que es aun más peligroso porque da una falsa sensación de seguridad.

¿Y ya que estamos, como se resolvería este “engaño” en el que el MAIL FROM es distinto del From:? Pues hay un check de SpamAssassin que hace exactamente eso, se llama HEADER_FROM_DIFFERENT_DOMAINS. Pero claro, SpamAssassin se aplica con posterioridad a la transacción SMTP.

Conclusiones

En primer lugar quiero aclarar no considero que el test realizado esté mal hecho, el planteamiento del autor era que el test no fuera muy intrusivo, y con ese planteamiento poco más podía probar. En ese sentido el test es impecable.

Lo que afirmo es que con las pruebas realizadas no se pueden sacar conclusiones sobre el nivel de protección de un dominio ante “ataques del CEO” o cualquier otro tipo de phishing y/o SPAM. Las razones de esta afirmación (que he detallado en los párrafos anteriores) son:

  • Se prueba una parte ínfima de la capacidad de filtrado de los servidores de correo
  • La probabilidad de falsos positivos es altísima (como mínimo TODOS los que aplican DKIM)
  • La probabilidad de falsos negativos es altísima (lo que hay que falsear no es el MAIL FROM de la transacción, es el From: del DATA)

Sacar las conclusiones presentadas en base a las pruebas realizadas sería equivalente a concluir que se puede robar dentro una casa porque la verja del jardín no tiene cerradura de seguridad, cuando una vez dentro podríamos encontrarnos puertas de seguridad, perros, alarma, videovigilancia y guardias armados.

¿Creo que hay muchos falsos positivos y que en realidad la cantidad de dominios “vulnerables” es menor a la del estudio? ¡En absoluto! de hecho creo que es muy probable que la mayoría de esos dominios que no aceptan el falseo del MAIL FROM, se tragarían el From falseado. Es decir, creo que puede haber una gran cantidad de falsos negativos.

Y si pienso que probablemente hay aún más dominios vulnerables a este ataque que los mencionados en el estudio, ¿por que he dicho que es “alarmista”?

Porque en mi opinión el alarmismo está en la coletilla de “por seguridad insuficiente de la mayoría de proveedores de hosting en internet”. El “falseo” de email no es un problema “técnico” que pueda eliminarse con configuraciones en los servidores de correo. Es un problema de educación y formación de los usuarios. Por supuesto que desde los servidores podemos tratar de “minimizarlos”, pero cuando en un servidor se aplican medidas antispam muy restrictivas, empiezan a llegar quejas porque se están descartando correos legítimos. Y además, tal como ya he argumentado, estas medidas antispam se aplican en fases posteriores a las analizadas en este test.

Existen mecanismos que casi podrían eliminar el problema, pero no serán totalmente efectivos hasta que todos los dominios lo adopten (SPF, DKIM, DMARK, etc). Es más, desde hace muchos años los usuarios tienen un sistema infalible para evitar correos falsos: firmar digitalmente los correos con S/MIME o PGP/GPG, pero claro, nadie sabe usarlo. Sería más efectivo enseñarles a usarlo, que aplicar complicadas medidas antispam, cuyos efectos secundarios serían que pueda no entregarse mucho correo legítimo.

Un efecto secundario de este estudio que creo que es muy peligroso es dar la sensación de que es un problema técnico de la infraestructura de correo, cuando en realidad es un ataque de ingeniería social, un simple “engaño” a la victima. Y que para evitarlo es mucho mas efectivo concienciar a los usuarios que tratar de bloquearlos en los servidores (aunque evidentemente tenemos que hacer ambos: defensa en profundidad)

Y lo mejor que podemos hacer para evitar estos ataques es pedirle a los usuarios que repitan con nosotros: El email es una postal, el email es una postal, el email es una postal, …