Cartuxeira: Recurriendo a las Meigas ( y al Machine Learning) para protegerse del Phishing

Este año hemos presentado en RootedCON 2023 el proyecto “Cartuxeira”, cuyo objetivo es proporcionar la información necesaria para evaluar si un mensaje de e-mail es confiable o no, haciendo uso de técnicas de Machine Learning e información recopilada de fuentes abiertas, para minimizar así, el riesgo de sufrir ataques de Phishing.

Figura 1: Cartuxeira - Recurriendo a las Meigas ( y al Machine Learning)

 para protegerse del Phishing

En el folclore gallego, Cartuxeira es un tipo de meiga que echa las cartas y siempre acierta en sus vaticinios, y parece que, desde el Siglo XIX que nacieron los primeros “spam” con los casos del denominado prisionero español, las meigas gallegas pare cen ser las únicas que podrán sacarnos de este problema. Por cierto, en el libro de Machine Learning aplicado a Ciberseguridad, se explica en el Capítulo VI un ejemplo aplicado a clasificar Spam, en "Cartuxeira", vamos a hacerlo con el Phishing y añadiendo OSINT.

Figura 2: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández.

A día de hoy, la principal herramienta que cualquier ciudadano de a pie dispone para luchar contra el Phishing es la concienciación. Sin ir más lejos, y aprovechando para recordar las recomendaciones de seguridad del INCIBE contra el Phishing, lo primero en lo que hay que fijarse es en el remitente y su dirección de e-mail y si confiamos en ella. Lo segundo, el asunto y objetivo del e-mail y ver si traslada urgencia o trata de que compartamos información de carácter personal como usuario y contraseña de alguno de los servicios que utilizamos o nuestra información financiera o medios de pago. El tercer punto es revisar si la redacción del mensaje es correcta. Y por último, los enlaces y documentos adjuntos en dicho e-mail.

Figura 3: Recomendaciones de seguridad del INCIBE ante ataques de Phishing

Este tipo de recomendaciones de seguridad pueden tener llegada y calado siempre y cuando se tengan conocimientos básicos de informática, pero en el caso de todas esas personas mayores, como por ejemplo padres o abuelos, que se están viendo empujados a la digitalización sin conocimientos de informática, pueden no ser suficientes. 

Sin ir más lejos, si tu madre recibe un e-mail de “Amazon” con dirección “info [at] ammazon [dot] com”, ¿cómo le explicas que el dominio contratado por la empresa es con una “m” y no con dos si está viendo que el nombre del correo es Amazon? ¿Te pondrías a explicarle WHOIS, y registros DNS como el A y el MX? 

Y ya ni hablemos de DMARC, SPFv1 o SPFv2, SenderID o DKIM en este "caos" maravilloso que el correo electrónico y que ha hecho que la dirección de e-mail se haya convertido en nuestro usuario de los servicios de Internet.

Estado del arte del Phishing e importancia de la dirección de email

Desde luego, si la única arma contra el phishing es la concienciación, nos espera un largo invierno por delante. Sin ir más lejos, en 2022 España se situó como el tercer país a nivel global con más amenazas detectadas vía e-mail con el 21% del total y sexto a nivel de ciberataques detectados y recibidos. Teniendo en cuenta los diferentes nombres sexys del Phishing (Phishing, Vishing & Smishing), el 96% de todos esos ataques se realizaron vía correo electrónico, lo cual, con tecnologías como ChatGPT y su capacidad para realizar redacciones realistas de correo, empieza a complicarse mucho el identificar fallos gramaticales en el cuerpo del mensaje por parte de un humano. Por este motivo, ¿por qué no poner foco en el primer punto de la concienciación?: la dirección de email.

Figura 4: Partes de una dirección e-mail

Si observamos una dirección de e-mail, podríamos analizarla desde cuatro puntos de vista diferentes. El primero, el dominio, para el cual podríamos revisar si está en blacklist, se ha generado utilizando técnicas DGA, o con fines maliciosos vía cybersquatting (ocupación del dominio) y la búsqueda de estos como forma de proteger tu empresa. En segundo lugar, la dirección de e-mail al completo, que del mismo modo nos permite revisar si está en blacklist o se ha creado con malas intenciones. En tercer lugar, la actividad de dicho e-mail, si tiene presencia en Internet y desde cuándo, leaks en los que aparece, etcétera. Y por último, algo ya más vinculado al mundo empresarial sería el enfoque del KYC (Know Your Customer) en el que se vincula dicha dirección con IP o identidad digital de una persona concreta.

Técnicas utilizadas para generar e-mails de Phishing (DGA y EGA)

En primer lugar, cada vez más se están utilizando técnicas heredadas del mundo del malware como la generación de dominios vía DGA (Domain Generation Algorithm). Este tipo de técnicas funcionan similar a como funciona un token hardware o software que genera una OTP. En este caso, el atacante genera un algoritmo de generación de dominios y una semilla aleatoria que es la misma que la incorporada en el malware. De este modo, el servidor de Command & Control va dando de alta y baja los dominios en el DNS de manera automática y el malware desplegado, con la sincronización de su semilla, genera los mismos dominios para poder conectarse a él fácilmente. 

Figura 5: Diagrama explicativo del uso de DGA en malware

Esto obviamente dificulta una gestión de blacklisting por parte de los equipos de seguridad en cualquier organización. Sendos ejemplos de e-mails generados con este tipo de técnica los recibimos a día de hoy sin parar en nuestras bandejas de entrada y de Spam como se puede observar en los ejemplos de la siguiente figura.

Figura 6: Ejemplo de phishing generado con técnicas DGA

Por otro lado, también existe otra técnica que es mucho más difícil de detectar y que en este trabajo hemos acuñado como algoritmos de generación de e-mails o EGA (Email Generation Algorithm). Esta técnica se basa en engañar al ojo humano aprovechando la funcionalidad (o bug) de nuestro cerebro que nos permite realizar una lectura predictiva aunque las letras de la palabra estén mal escritas. 

Figura 7: Ejemplo de cómo funciona la lectura predictiva de nuestro cerebro

Éste es un campo de neurociencia bastante interesante, del cual, un artículo académico ha impulsado nuestro trabajo de investigación hacia este enfoque: A. Agrawal, KVS Hari and SP Arun, “A compositional neural code in high-level visual cortex can explain jumbled word reading”, 2020. 

Figura 8: Ejemplo de generación de e-mails vía EGA

Teniendo en cuenta este aspecto, la siguiente figura muestra los casos de uso contemplados dentro de nuestro término acuñado EGA, el cual incluye el cybersquatting, para el correo legítimo de Netflix.

Proyecto Cartuxeira

Cartuxeira es un servicio cuyo objetivo principal es identificar ataques de Phishing analizando exclusivamente la dirección de e-mail. Para ello, este proyecto utiliza técnicas de Machine Learning e información de fuentes abiertas OSINT para la identificación de e-mails maliciosos. 

Figura 9: Cartuxeira en GitHub

Una de las premisas que hemos tenido a la hora de desarrollar este proyecto ha sido su simplicidad de utilización y despliegue. Por ello, todo el código fuente de la solución se puede encontrar (incluyendo modelos de Machine learning) en GitHub.  La solución se ha dockerizado de tal forma que la arquitectura de Cartuxeira sería la mostrada en la siguiente figura:

Figura 10: Arquitectura de Cartuxeira

Como se puede observar en la arquitectura de Cartuxeira, existen diferentes componentes cuya información es agregada por el “Email Risk Composer” para retornar el riesgo identificado para el e-mail consultado. A continuación haremos zoom sobre los cuatro componentes que se muestran en la arquitectura.

DGA Detector

Como base de conocimiento para el DGA Detector, partimos de un dataset de 890.000 dominios legítimos y 225.000 dominios ilegítimos generados vía DGA. Tras el pre-procesado y el etiquetado de los datos, aplicamos un proceso iterativo de prueba de distintos modelos de Machine Learning y observamos que casi todos fallaban al detectar el dominio malicioso, incluso después de aplicar técnicas para aliviar el desbalanceo de la muestra. Esto sucedía en casi todos los modelos (RF, Regresión Logística, CNN) excepto en Perceptrón Multicapa (MLP), el cual detectaba con mayor precisión los dominios DGA que los legítimos. Aun así, los resultados no fueron lo suficientemente buenos como para considerar añadir estos algoritmos en la herramienta.

Figura 11: DGA-Detective en GitHub

En este escenario, decidimos incluir el proyecto DGA-Detective disponible en Github. Dicho proyecto ha sido desarrollado por el equipo de investigación SOCCRATES bajo financiación de la Unión Europea (Horizonte 2020). Su modelo se basa en redes TCN (Redes Neuronales Convolucionales Temporales), que son una variación de las redes neuronales convolucionales para tareas de modelado de secuencias, al combinar aspectos de las arquitecturas RNN y CNN.

Finalmente, al pasar nuestro dataset de prueba sobre el modelo de DGA-Detective, los resultados fueron de una exactitud de acierto del 96% y del 99% para cada una de las clases (No-DGA y DGA respectivamente), superando ampliamente al resto de modelos probados.

EGA Detector

Como base de conocimiento para el EGA Detector, hemos utilizado los leaks incluidos en el proyecto “Odin: Footprinting en la era del BigData” que se presentó en RootedCON 2016 entre Alejandro Ramos y Elías Grande. En dichos leaks encontramos 150 millones de e-mails, que tras eliminar duplicados e inconsistencias nos permitió disponer de 105 millones de emails legítimos. Por otro lado, recopilando e-mails reportados como maliciosos en Internet y abusando de la “feature” de lectura predictiva humana, generamos cerca de los 300 millones de e-mails maliciosos. 

Tras el pre-procesado y disponer de los datos etiquetados, aplicamos un proceso iterativo de prueba de distintos modelos: MLP, CNN, Regresión Logística y XGBoost. Los mejores resultados los presentó RandomForestClassifier (RFC), que es un ensamble de árboles de decisión donde la clase predicha es la más votada entre todos los árboles del ensamble. 

Este caso no es aislado ya que es algo frecuente que el algoritmo de clasificación RFC presente unos resultados mejores que sus compañeros clasificadores como se plasma en uno de los papers académicos más referenciados a día de hoy sobre el tema: M. Fernández-Delgado, E. Cernadas, S. Barro and D. Amorim, “Do We Need Hundreds of Classifiers to Solve Real World Classification Problems?”, 2014, .

Finalmente, tras aplicar técnicas de cross-validation para la optimización de los hiper-parámetros de RFC, la exactitud de predicción de los e-mails no legítimos (la precisión del modelo) es del 92% y el accuracy (precisión total del modelo) es de un 84%.

BlackList Service

La solución también incluye un servicio propio de blacklist tanto para e-mails como para dominios. Este servicio permite un “botón del pánico” para elevar el nivel de riesgo de aquellos e-mails que no hayan sido detectados como DGA o EGA. Además, el almacenamiento de estas blacklists sirve como base de conocimiento para futuros re-entrenamientos de los modelos ya que la degradación de los modelos de Machine Learning es común y de ahí que sea necesario los re-entrenamientos.

Servicios de terceros

Para cerrar el círculo, se ha enriquecido Cartuxeira con información de servicios de terceros. A esta información, al depender de la calidad del dato de cada servicio, se le da menos peso que a los cálculos realizados por los detectores DGA y EGA. Aun así, toda la información recopilada sirve para enriquecer de información la herramienta. Entre los servicios utilizados, destacamos DNSBL para la comprobación de blacklists, y Simple Email Reputation para la investigación de la presencia de un e-mail en Internet.

Conclusiones

Para finalizar, indicar que, un despliegue de Cartuxeira de manera centralizada en un organismo institucional o empresa puede beneficiar tanto a ciudadanos como empleados en la prevención del Phishing. Todo ello utilizando sólo direcciones de e-mail sin necesidad de analizar el cuerpo del e-mail o entrenar modelos con dicho cuerpo de los mensajes, lo cual podría suponer fuga de información confidencial (en función de la ubicación de los motores de Machine Learning) o problemas de privacidad por el contenido en cuestión.

Los algoritmos EGA plantean un nuevo enfoque a considerar, el cual abre múltiples vías de mejora e innovación gracias a la disponibilidad del código de Cartuxeira, para que por fin, la concienciación no sea la única herramienta disponible contra el Phishing.

Figura 12: Razones por las que usar un buzón de MyPublicInbox

para estar contactable en Internet

Por último, recordad que exponer vuestra dirección de e-mail en Internet no es la mejor de las ideas, hay otras formas de estar contactable en la red y ponérselo difícil a los que quieran robar tu identidad, a los que quieran enviar Spam o Phishing, servicios como MyPublicInbox nos ayudan a estar contactables en la red sin exponer a cualquiera tu dirección personal de e-mail (que te va a acompañar mucho tiempo en tu vida), y por ahí puedes contactar con nosotros también.

Autores: Elias Grande y Ana de la Torre

Contactar con Elias Grande

Contactar con Ana de la Torre

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)

Y llegamos a la última parte de esta serie dedicada a mi querido, caótico, y necesario sistema de correo electrónico, pero que a la vez forzamos para cubrir necesidades que no siempre puede cubrir. Como hemos visto hasta aquí, tiene muchas carencias que yo he querido resolver en esta pequeña lista que os dejo a continuación.

Figura 17: El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)

Como principales problemas con el correo electrónico, estos son algunos de los temas a los que nos tenemos que enfrentar, y aceptar, cuando lo utilizamos. Yo los he resumido en 10 puntos que recogen, más o menos, todo lo explicado en las tres partes anteriores.

1.- Identidad del remitente: Mientras no se utilice PGP o S/MIME, la identidad del remitente de una comunicación es siempre algo muy dudoso. Por eso existen los ataques de Phishing, aunque tengamos tecnologías de mitigación como Reverse MX Lookup, SPF, Sender ID y DMARC.

2.-  Privacidad: Las comunicaciones no siempre van cifradas extremo a extremo. El sistema de correo electrónico enruta los mensajes entre servidores que están en medio del camino entre el servidor de correo saliente y el servidor de correo entrante, y mientras el usuario no cifre sus mensajes con PGP o S/MIME, los mensajes pueden pasar por tramos sin cifrar, aunque se use SMTP-S, POP3-S, HTTPs o Mutual-TLS en algunos tramos.

3.- SPAM: La posibilidad de que cualquiera pueda enviarte publicidad masivamente a tu dirección de correo electrónico es algo muy barato como para desdeñar su uso. Hemos puesto regulaciones como LSSI, LOPD o GDPR, pero muchas empresas no están sujetas a ellas o directamente las ignoran. Por supuesto, los Filtros Bayesianos, los sistemas de reporte de SPAM con interacción de usuario, las técnicas de Machine Learning y las DNSBL o RBLs (RealTime BlackHole Lists) mitigan el impacto, pero ni mucho menos acaban con él.

4.- Seguridad: Al igual que con la publicidad, las campañas de Fraude (ventas falsas, estafas "scams" etc..), de ransomware personal o empresarial, de exploits e instalación de R.A.T.s (Remote Administration Tools) para meter los equipos clientes en botnets, etc... hacen que el correo electrónico sea el canal preferido por todos.

5.- Confiabilidad: Debido a que tenemos que aplicar filtros anti-Spam, Anti-Phishing, y Anti-malware que no son perfectos ni mucho menos, tenemos una pérdida de correos legítimos de muchas personas, que pueden ser una oportunidad de negocio, una comunicación esperada o un mensaje necesario para una gestión, lo que hace que muchos acabemos llamando por teléfono a las personas a las que enviamos mensajes importantes para garantizar que el mensaje ha llegado.

6.- Productividad: Algunas personas dedican hasta cinco (5) horas al día de su tiempo a procesar el correo electrónico, lo que hace que su productividad no se esté viendo siempre mejorada por el uso de un sistema de comunicación como el e-mail. Esto se debe a que el coste de enviar un correo electrónico es prácticamente cero, muchas personas no hacen un uso responsables de las comunicaciones y tienen en cuenta el tiempo que debe invertir el (o los) receptor(es) en su lectura y contestación.  A la gente le sale barato robar tiempo de la vida profesional o personal por medio de un mensaje de e-mail.

7.- Trabajo extra: Si el miedo a perder mensajes hace que configuremos umbrales a los filtros muy pequeños, o que nos repasemos la carpeta de mensajes de Correo No Deseado cada día, los usuarios comenzarán a hacer tareas extras de borrado y clasificación de mensajes buenos o malos, revisando entre correos de spam, malware, estafas, etcétera, aquellos que son realmente útiles para el receptor.

8.- Identidad Personal: Como os he dicho antes, el uso de la dirección de e-mail como identidad en los servicios de Internet, ha hecho que compartir tu dirección de correo electrónico se convierta en una forma de desvelar todos aquellos sitios en los que tienes 

9.- Disponibiliad: Debido a todo lo anterior, las personas suelen optar por dos alternativas. O no compartir fácilmente su dirección de correo o compartir una dirección de e-mail que deja claro que no es la suya personal. En el primer caso, se produce un efecto de indisponibilidad, ya que el que realmente quiere contactar contigo por algo útil ve dificultada su tarea, generando una pérdida de mensajes que podían ser relevantes para las personas. Un efecto contrario al origen de la comunicación.

10.- Impresonalidad: En la segunda opción del punto anterior, las personas tienen a poner un buzón impersonal como forma de contacto, lo que rechaza la comunicación. No se sabe quién está detrás de ese buzón, así que genera un rechazo en las personas ya que nos imaginamos a un conjunto de personas procesando esos mensajes. Es decir, perdemos de nuevo comunicaciones.

¿Y qué hemos hecho en nuestra vida personal?

Pues nos hemos tirado a otros tipos de comunicación. En la comunicación personal nos hemos movido hacia las Redes Sociales, que son, en contrapartida con el correo electrónico, unos de los sistemas menos interoperables del mundo. Así, tenemos cuentas en Facebook, Twitter, Linkedin, Telegram, WhatsApp, Instagram, iMessage, Twitch, etcétera. En todos estos sistemas hay sistemas de comunicación en forma de chats, comentarios o mensajes privados como e-mails. Pero de nuevo se produce un problema de productividad brutal.

Figura 18: David Guapo sobre el uso de WhatsApp

Dar tu WhatsApp implica dar tu número de teléfono a personas que pueden llamarte, buscar tus identidades en la red o hacer un uso intenso de mensajería. Yo no tengo tarjeta de visita, no doy mi correo electrónico personal y mi número de teléfono lo guardo como si fuera mi tesoro. Y WhatsApp, Telegram, o iMessage están restringidos hasta más no poder. Porque además dicen cuándo estás online. Por supuesto, si lo doy poco, utilizar WhatsApp, Telegram o Instagram como alternativa al e-mail contactos con terceros a través de Internet, es algo que no me planteo.

En cuanto a las redes sociales, sucede un poco lo mismo, abiertas a todo el mundo con mucho tiempo para que pueda pedir cualquier cosa de manera gratuita. Supongo que todos os habréis topado con mensajes no solicitados de gente que no sabéis quién son que piden cosas que os llevan tiempo. En mi caso, los mensajes de hackear a la pareja son un clásico, y por supuesto, dejé de contestar por redes sociales.

View this post on Instagram

Como diría Bon Jovi ...”it’s my life”... solo cuatro de los últimos más de 200. ¿Por que no me escribirá la gente para invitarme a cenar en vez de estas cosas?

A post shared by Chema Alonso (@chemaalonso) on Sep 3, 2019 at 10:30pm PDT

Una en particular es muy curiosa, Linkedin, que deja que cualquiera que quiera enviarte un mensaje pueda hacerlo. No es necesario que sea tu contacto, basta con que les pague a ellos por poder enviarte un mensaje. Es decir, ellos comercializan tu contacto y venden tu tiempo, pero eres tú el que tengo que contestar, y hoy en día se ha convertido en una canal muy usado para ventas. 

¿Y en la vida profesional?

Muchas empresas aún sufren en productividad por el uso intenso del e-mail. Yo me enfado cuando me envían correos kilométricos o con muchas personas en copia. De hecho, suelo hacer caso omiso de un mensaje que me tiene en copia con muchas personas. Lo siento, tengo muchos mensajes que leer que van dirigidos solo a mí. Y por supuesto, los hilos infinitos de veinte mensajes deberían ser causa de despido inmediato. 

Es la peor de las productividades. Si una persona hace eso en lugar de llamar por teléfono o arreglar la solución en una reunión personal, es que esa persona sobra en el equipo. Y si la empresa lo consiente, es que hay un problema de gestión serio.

Por eso se han intentado muchas cosas, y algunas ha fructificado. En Google, que tenían Gmail se dieron cuenta de esto internamente, y decidieron apostar por Google Wave, un nuevo sistema de comunicación para grupos que cambiaba el mensaje de e-mail tradicional por algo diferente, pero no triunfó y en el año 2012 se cerró el proyecto.

Figura 20: Imagen del proyecto Google Wave

Microsoft apostó por una cosa similar en SharePoint, del que yo mismo participé en un libro de Seguridad en SharePoint 2010 junto con mi hermano Rubén Alonso y otros compañeros para ver temas de auditoría de seguridad en la plataforma y del que apenas quedan una decena de unidades antes de desaparecer para siempre. Y a base de integrarlo con Microsoft Office y el resto de tecnologías en la empresa ha ido consiguiendo perdurar, aunque no es precisamente el más querido por muchos grupos de usuarios empresariales que necesitan otras formas de comunicación.

Figura 21: Libro de Microsoft SharePoint 2010: Seguridad

Sistemas como Skype o Google Hangout - y los canales IRC en grupos de seguridad - se convirtieron en buenas alternativas en la empresa para las comunicaciones, pero al final han sido Slack y Microsoft Teams los que han dado el salto para tener sistemas de comunicación en grupos de trabajo similares a los que Google Wave proyectaba. Es decir, un lugar donde se centralicen los documentos, se puedan editar, se permitan reuniones en real-time o mensajes en diferido.

Con todas estas alternativas, las personas se han ido buscando formas diferentes de suplir al correo electrónico y evitar todos los problemas anteriores. Hoy en día, mi equipo personal y compañeros me mandan un WhatsApp que contestaré cuando pueda, pero seguro que mucho antes que un e-mail, y los desarrolladores y equipos de producto usan Slack o Microsoft Teams antes que enviar infinitas listas de mensajes de e-mail.

Por supuesto, también quedan cosas que solucionar, como lo que sería publicar un e-mail de contacto al exterior que no sufriera los diez puntos anteriores, pero en eso también estamos trabajando, porque está claro que ni las redes sociales ni las soluciones empresariales que he citado, ni el e-mail tradicional arreglan todos esos problemas.

Resurección

Los seres humanos necesitamos comunicarnos. Para socializar. Para trabajar. Para demostrar que estamos enfadados. Para decirle a esa chica que te gusta mucho. Para educar a nuestros hijos. Y en todos estos momentos el e-mail ha sido una pieza fundamental en las últimas décadas de nuestra existencia.

Como hicimos en el pasado cuando pasamos del copiar ficheros de texto de una carpeta a otra para dar el salto a SMTP y POP3, tendremos que aceptar los nuevos cambios. La disrupción está llegando a esa dirección de e-mail y tendremos que pensar en cuáles serán las funciones de ese tunombre@tuhost.com que tanto hemos utilizado en los últimos años. Tal vez sea solo para compañeros y amigos y totalmente privado. Tal vez solo sea para la gestión de la identidad.

O tal vez sea un concentrador de comunicaciones privado que debemos proteger y que interactuará con los sistemas empresariales tipo Slack o Microsoft Teams, y las redes sociales personales sin nunca ser revelado. Un concentrador que no deba ser expuesto en la red nuca para evitar todos los problemas que he citado en los puntos anteriores.

Lo que sí que tengo claro es que hemos extenuado el modelo con tantos parches, y las nuevas tecnologías están robándole cuota de uso práctico, mientras que seguimos teniendo una carga en su gestión y un foco de riesgos de seguridad y privacidad personal y empresarial.

Eso sí, contar nuestra historia como seres humanos sin hablar del e-mail sería injusto. Sería inexplicable Internet sin uno de sus servicios mágicos, míticos y más poderosos que hemos tenido la suerte de utilizar. Así que, ¡Larga vida al e-mail! Aunque tengamos que acotar o re-definir sus usos.

Saludos Malignos!

Autor: Chema Alonso Contactar con Chema Alonso

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)

Como hemos visto en la parte anterior de este artículo, ya habíamos solucionado los problemas de usabilidad e interconexión entre los diferentes ecosistemas de usuarios, para que todos ellos pudieran enviar y recibir correos utilizando todo tipo de clientes de escritorio, web, móviles, etcétera a usuarios que se encontraran en cualquier otro destino. Se había conseguido una infraestructura global e interconectada, algo que desde luego no han fomentado las redes sociales en versiones posteriores y de lo que hablaremos un poco más adelante.

Figura 4: El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)a

Con la construcción de esta infraestructura global interoperable y compatible para la comunicación, aparecieron los primeros problemas de seguridad, que tenían que ver más con las comunicaciones sobre Internet, un medio que se definió de forma insegura sin un modelo de amenazas claro desde el principio, lo que nos llevó a aplicar las primeras soluciones de cifrado y firma digital para garantizar la integridad y confiabilidad de la información que sobre el e-mail se envía.

Para el cifrado y la firma digital de los correos electrónicos aplicamos túneles SSL a los protocolos de red, y para el cifrado y la firma digital de los mensajes se puede utilizar a día de hoy S/MIME (certificados digitales para e-mail) o PGP (Pretty Good Privacy), que permiten firmar y cifrar extremo a extremo - sin contar con que los servidores de correo electrónico aplican una capa de seguridad o no -. Los clientes de correo electrónico, por su parte, avisan a los usuarios del nivel de cifrado y privacidad utilizado en cada uno de los mensajes. Pero no es suficiente ni mucho menos para todas las amenazas que fueron apareciendo.

Más soluciones de seguridad para saber de dónde viene un correo:
Reverse MX Lookup, SPF, SenderID, DKIM & DMARC

Con el escenario de envío masivo de mensajes no solicitados a direcciones de correo electrónico comenzamos a poner un montón de soluciones para ir tapando la sangría de problemas que supone para una persona y una organización – no olvidemos que el 90% de los APTs de seguridad han provenido por un correo electrónico en un ataque de spear phihing enviado a una persona de la empresa - que su buzón de correo electrónico esté abierto y disponible para cualquiera que conozca la dirección.

En esta primera remesa de soluciones vamos a intentar centrarnos en el problema de la suplantación del remitente o e-mail Spoofing, que da lugar a los ataques de Phishing y Spear Phishing. Por supuesto, la firma digital S/MIME y PGP son lo ideal, pero como hemos dicho repetidas veces, no es muy popular en el mundo global.

Reverse MX Lookup

Para evitar que suplantaran las direcciones de correo electrónico de nuestra organización, es decir, que nadie pudiera enviar mensajes de correo en nuestro nombre como se hace en los ataques de phishing, comenzamos a indicar cuáles eran los servidores de correo electrónico que pueden enviar mensajes con un remitente de nuestro dominio. La primera solución fue sencilla, pero inútil. Como al principio el servidor de correo entrante - donde están los buzones y se implementan POP3 - era el mismo que por el que salían los correos electrónicos - donde se implementa SMTP - algunos servidores de correo comenzaron a aplicar el filtro de Reverse MX Lookup.

Para saber dónde está el servidor de correo entrante de una organización, en el servidor DNS de esa organización se crea un registro especial llamado MX (Mail eXchanger) que apunta a la dirección IP o hostname del servicio que recibe el correo electrónico de ese dominio. Lo que hacían algunos servicios de correo electrónico entrante es rechazar cualquier correo electrónico que viniera de @otrodominio.com si el servidor que entregaba ese mensaje no tenía la dirección que tenía alguno de los registros MX del dominio otrodominio.com.

Como os podéis imaginar, cuando los servidores de correo saliente se separaron físicamente de los servidores de correo electrónico entrante, este filtro dejó de ser útil, ya que nunca coincidían las direcciones IP de los servidores que entregaban los mensajes con los registros MX. Por eso, hubo que crear otro registro. El registro SPF, donde se da la lista de cuáles son los servidores autorizados desde nuestra organización para entregar correos electrónicos que tengan como remitente uno de nuestros usuarios.

SPF (Sender Policy Framerwork)

Creando los famosos registros SPF (Sender Policy Framework) - también conocido como SPFv1 - se identifican los servidores de correo saliente que usa esa organización y qué debería hacer el servidor de correo entrante de un tercero si recibe un mensaje de este dominio que no viene de esos servidores identificados en SPF. A priori, suena como una medida útil, pero tiene muchos "peros" a la hora de su implementación y uso.

Figura 5: Registro SPF de Gmail.com.

Por desgracia, como las empresas tienen cedidos "alias" de correo de sus dominios a campañas de de marketing que se envían desde servidores externos a la organización o que no son controlados por ellos, la política de seguridad suele ser “Softfail” que se identifica con un "~". Para que os hagáis una idea, cuando usamos SPF lo que hacemos es irnos al DNS de nuestra empresa y decir algo como:

"Estos son los servidores que pueden enviar correo de @miempresa.com o @mibanco.com. Si te llega un correo de alguien que dice que es de @mibanco.com debes aplicar esta política."

La política más férrea debería ser “Hardfail” (-), o lo que es lo mismo, “tíralo y no lo entregues al destinatario, que es falso”, pero por desgracia sucede lo que he comentado antes, y las políticas son “Softfail” o lo que es lo mismo:

 “Míralo bien y ponlo un poco en alerta, pero no estoy seguro de que no sea mío”.

La cosa se complica a la hora de detectar si un registro realmente viene de una organización o no, yo que hay muchas variantes. Muchas personas tienen delegada la gestión de su buzón de correos a terceros, por lo que hay casuísticas en las que una persona manda un mensaje en nombre de otra.

SenderID o SPFv2 (antes conocido como CallerID)

Así, en un e-mail tenemos los campos from, pero también sender y también resent-from y resent-sender. y es ahí donde apareció el estándar SenderID, empujado por Microsoft, y conocido como SPFv2. Su idea es garantizar que el remitente de un correo viene realmente de la organización que tiene el servidor de correo electrónico que lo entrega.

Así que, determinar si un correo electrónico viene o no de una organización realmente es complejo. SenderID intentó centrarse en identificar esa casuística del emisor, pero no consiguió ser un estándar de facto, y su aplicación fue residual en el mundo de Internet, así que encontrar registros SPFv2 con políticas Hardfail fue como localizar un unicornio o un mirlo blanco.

De hecho, al final, se utilizan otras cabeceras como Return-Path y X-Return-Path (las cabeceras X- no son parte del estándar oficial y son introducidas por servidores de correo electrónico para dejar información extra que consideran útil hasta que son estandarizadas... o no.)

DKIM (Domain Keys Identified Mail)

Intentar determinar que un mensaje no es legítimo cuando la situación es tan completo hizo que SPF no fuera el único estándar que salió para evitar la suplantación de los remitentes en los mensajes de correo. Y así nació DKIM, con una aproximación distinta, tratando de decir algo como:

"No sé si este correo electrónico que viene de un servidor que no conozco y un resent-from o resent-sender extraño es un correo electrónico legítimo de esta organización o no, pero este otro que viene firmado por uno de mis servidores de correo saliente sí que es mío y puedes estar más que seguro de que su contenido es legítimo."

Como veis, la idea de DKIM (Domain Key Indentified Mail) es que cada correo electrónico que ha salido de un servidor autorizado de la organización, va firmado por una clave privada que tiene configurado el servidor de correo saliente y cuyo par de clave pública está accesible para todo el mundo en el servidor DNS de la organización y se puede consultar.

Figura 6: Clave DKIM usada por un servidor de yahoo.com

Es decir, recibo un correo de paco@yahoo.com y en el texto del mensaje aparece una cabecera DKIM con un HASH, que se supone que ha generado el servidor de correo saliente de Yahoo.com que ha entregado el correo. Así que se mira qué servidor ha entregado el correo, nos vamos al servidor DNS de Yahoo.com, pedimos la clave pública DKIM de ese servidor y comprobamos que el hash que nos han entregado es correcto.

Figura 7: Correo de Ebay firmado correctamente por DKIM

Como veis, la aproximación es diferente, mientras que con Reverse MX Lookup, SPF o SenderID se trata de eliminar lo que no venga entregado desde el dominio correcto, con DKIM se trata de indicar que, si el correo ha llegado desde la IP correcta, el usuario lo sepa con un icono especial, tal y como podéis ver en esta captura con correos de Ebay tiempo atrás. Pero como la mayoría no lo usa, pues otro intento fallido para diferenciar los correos legítimos de los no legítimos.

Como veis, el uso de Reverse MX Lookup, SPF, SenderID y DKIM hace que haya mucha información en el cuerpo de un mensaje para analizar un correo electrónico. Esta información no es concluyente ninguna por sí misma, ya que los casos son muchísimos, y es lo que hizo que los clientes de correo electrónico no se atrevieran a marcar definitivamente un mensaje como malo o como bueno.

El Proyecto "Apolo"

Para poder dar más información al usuario, nosotros creamos en Informática 64, un plugin para el navegador que se leía el cuerpo de los mensajes en el cliente web de Gmail y Hotmail, buscaba la información SPF, DKIM, SenderID, las direcciones IP en los registros MX y hacía las comprobaciones desde el propio navegador, y luego mostraba información de ayuda al usuario sobre los mensajes de correo electrónico que estaban en su bandeja de entrada. Fue un proyecto de investigación más que una verdadera herramienta, pero lo llamamos el Proyecto Apolo.

Figura 8: Información del proyecto Apolo

Si el registro SPF era correcto en el mensaje, mostramos un icono verde. Si no cumple DKIM, ni Sender ID, ni SPF, ni MX Reverse Lookup, lo poníamos en alerta roja. Una prueba para dar más información a los usuarios avanzados.

DMARC (Domain-based, Message Authentication, Reporting & Conformance)

Al final, lo que nosotros hicimos en el Proyecto Apolo tenía todo el sentido. Había que hacer algo que mezclara todo, y así, tiempo después, nació DMARC. El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 9: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -, para lo que vamos a necesitar alguna tecnología extra.

PCL (Phishing Confidence Level)

Al final, ni con DMARC se garantiza que un mensaje no sea malicioso. Existen casos concretos en los que es posible pasar DMARC o no hay información suficiente para tomar una decisión firme. En algunos mensajes habrá información de Return-Path o X-Return-Path útil. En otros habrá información de direcciones IP que podremos consultar en bases de datos de salud que nos dirán si son de hosters que nunca hacen ataques o de otros con "mala reputación". Además, si miramos el cuerpo del mensaje podremos ver si tienen textos utilizados normalmente en ataques de phishing o no, etcétera.

Figura 10: Configuración de umbrales PCL en Microsoft Outlook

Es decir, que si independientemente de los estándares que intentan garantizar que un mensaje viene o no viene de un determinado dominio, podemos aplicar técnicas avanzada de Machine Learning a los mensajes que utilicen toda la información en el mensaje disposnible, y todo el conocimiento histórico que tengamos de nuestro correo electrónico para generar un índice, que llamamos PCL (Phishing Confidence Level) y que generar mi servidor de correo para clasificar el mensaje en función del número que salga.

Así, creamos unos umbrales para decidir qué mensajes entran en la carpeta de entrada, cuáles entran en ella pero con funcionalidad limitada - carga de imágenes, alertas mostradas y deshabilitación de funciones -, cuáles van a la carpeta de Spam y cuáles no se entregan al buzón.

Es un trabajo avanzado e ímprobo, y muchas veces tiene errores, pero es la solución que aglutina todos los intentos anteriores existentes para sacar el máximo de la información disponible. Además, para poder tener la información actualizada y el PCL vaya ajustándose, es necesario contar con la colaboración de los usuarios, que deberán ir reportando aquellos mensajes sospechosos. Pero esto es solo para los ataques de Phishing.

Y aún así no son suficientes y se intentan cosas nuevas.

Aún nos queda el SPAM por donde vienen la mayoría de los problemas de malware, robo de tiempo de las personas para convertir el e-mail en improductivo y molesto para las personas. Y mucho peor, los problemas de identidad asociados a las direcciones de correo electrónico, así que nos queda mucho por hablar todavía de la muerte y resurrección del e-mail.

Como os podéis imaginar, a pesar de todas estas tecnologías, el correo electrónico sigue siendo un caos. Al final un mensaje puede entrar en el buzón de entrada de un destinatario o no dependiendo de la configuración de estas tecnologías en su servidor de correo, lo que permite que un mensaje de Spam o un Phishing puedan entrar o no dependiendo de la configuración que tengas.

Nos quedan muchas cosas, y lo iremos viendo en las partes siguientes de este artículo. Espero que estéis disfrutando la lectura tanto como yo la escritura.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************

¿Cómo están las protecciones contra ataques de phishing en las entidades bancarias latinoamericanas?

Los cibercriminales usan las técnicas que más beneficios económicos les generen, sin importar que esta técnica sea antigua. Siempre que siga siendo efectiva será usada para obtener sus objetivos. Este es el caso de los ataques de phishing a los bancos, una técnica muy usual para engañar a los usuarios tanto en ataques de Spam Phishing (masivos y a día de hoy altamente detectados) o de Spear Phishing (dirigidos y mucho más peligrosos).

Para que sea más efectiva esta vieja técnica, los delincuentes utilizan otro mecanismo también con mucha antigüedad, que es la suplantación o "Spoofing" de direcciones de correo electrónico, con el cual los cibercriminales se hacen pasar por entidades o empresas reconocidas, principalmente del sector bancario.

Figura 1: ¿Cómo están las protecciones contra ataques de
phishing en las entidades bancarias latinoamericanas?

Para atenuar el impacto de estas técnicas, desde hace mucho tiempo se han venido desarrollando tecnologías de protección para detectar la suplantación de direcciones de e-mail, como los los mecanismos SPF (Sender Policy Framewok), SenderID, DKIM (Domain Keys Identified Mail) o DMARC (Domain-based Message Authentication, Reporting & Conformance).

Estas medidas de atenuación deben ser configuradas por todas las empresas, pero especialmente por las entidades bancarias, quienes son las principales víctimas de la suplantación de sus direcciones de correo electrónico.

Un estudio con la banca en Latinoamérica

Como estos ataques siguen generando impactos económicos y reputacionales muy grandes uno espera que todos estos controles estén correcta y estrictamente configurados. Para comprobar si esto era así, me decidí a hacer un análisis de estas medidas en las 25 principales entidades financieras de Latinoamérica, que por nacionalidad son:

Figura: Distribución por países de las organizaciones en el estudio

El análisis no es muy complicado ya que basta con mirar la configuración de los registros adecuados en el DNS, y para automatizarlo utilicé la herramienta de SpoofCheck, que permite validar la posibilidad de suplantar estos dominios de correo. Los resultados no fueron buenos, ya que como se puede ver desafortunadamente estas medidas no están implementadas de forma adecuada en la mayoría de los casos, pues solo 2 entidades tienen correctamente implementadas las medidas de SPF y DMARC.

Figura: Resutado de las pruebas con SpoofCheck en las 25 entidades

Al entrar al detalle de las configuraciones, es posible darse cuenta que la mayoría de las entidades sí configuran las medidas de mitigación que técnicamente se pueden implementar, pero no realizan un proceso de fortificación para hacer que estás sean robustas y que garanticen un control efectivo.

Como se puede ver en la gráfica solo existen 2 entidades que tienen ambos controles configurados de forma robusta, pero es más crítico que existen 3 entidades que no tienen implementado ninguno de los controles. Esto lo que evidencia que la implementación de los controles en el DNS no son correctamente configurados, exponiendo a los usuarios a ser víctimas de una suplantación.

Figura: Nivel de seguridad brindado por las medidas SPF y DMARC

En la Figura 4 se puede apreciar que los controles se marcan con una implementación débil, por lo que se revisan las sentencias en el DNS de cada uno de los dominios para sacar la característica que genera esta calificación en cada una de las herramientas.

En el caso de SPF, que es la medida de seguridad más veces configurada, se permite registrar dominios y direcciones IP autorizados para ser emitir correos electrónicos a nombre del dominio de la entidad y al final de la sentencia se indica la severidad con la que se debe tratar a los correos que no cumplan las anteriores características de origen descritas para ser rechazados.

Figura: Ejemplo de configuración de un registro SPF

Este mensaje final tiene cuatro niveles de calificación, desde que cualquiera pueda enviar hasta totalmente restrictiva, por lo que al analizar las sentencias de DNS configuradas por las entidades financieras se detecta que la mayoría tienen la configuración en lo que se denomina “softfail” que se interpreta usualmente como que es posible que ese origen sea un remitente válido.

La configuración de DMARC es mucho menos usada y solo 2 entidades la configuraron de forma que garantiza que la política aplicada por los receptores cuando un mensaje no contenga los datos de autenticación, reporte y conformidad, sea rechazada o puesta en cuarentena. Esta política es la que se configura en la sentencia de DNS donde se configura el DMARC.

Figura: Flujo de funcionamiento de DMARC

Al revisar la configuración en los dominios de las entidades financieras, se encuentra que solo dos entidades tienen configurada la política que implica rechazo o cuarentena y en 10 entidades la política esta marcada como “none” lo que permite que el correo fraudulento pase sin que se le aplique una restricción.

Reflexiones finales

En conclusión, las principales entidades financieras de Latinoamérica tienen controles implementados para evitar que sus clientes sean víctimas de ciberdelincuentes que usando el correo electrónico, sin embargo, la efectividad de estos controles no es todo lo robusta que podría ser debido a que usan configuraciones que no garantizan la implementación de políticas de restricción para los servidores que reciben correos fraudulentos. Cuanto mejor estén las medidas de seguridad, más alto será el PCL (Phishing Confidence Level) de los mensajes de correo y más fácil será detectarlos en los sistemas de seguridad de los servidores de correo electrónico.

Figura: Valores PCL utilizados en Outllook para detectar Spam/Spear Phishing

En muchos clientes, con nuestro sistema de pentesting persistente, detectamos la misma situación, y esto suele ser debido a una mala gestión de los canales de comunicación vía e-mail de la empresa. Es decir, se suelen dar casos en los que las newsletters, las listas de distribución de e-mails o campañas concretas de comunicación vía correo electrónico, se delegan en terceras empresas, que envían mensajes desde servidores no corporativos, que adolecen de medidas de seguridad similares, lo que hace al final que haya que rebajar la configuración global de seguridad.

Y esto genera muchos problemas en las empresas que se preguntan después ¿por qué mi correo llega como spam? Una configuración robusta y segura de las medidas de seguridad no solo ayuda a mitigar el Spam Phishing, el Spear Phishing y el Spoofing, sino que además reduce los SCL (Spam Confidence Level) de los mensajes que son enviados desde la compañía lo que ayuda a tener un mejor negocio electrónico.

Por último, hay que recalcar que estos mecanismos de seguridad no son nada más que una pequeña pieza dentro de la estrategia de seguridad contra el fraude y los ataques de phishing dentro de una organización financiera, ya que se utilizan muchos otros sistemas de vigilancia digital, alerta y detección temprana desde los SOCs y controles en el uso de credenciales robadas, así que no se puede tomar estas configuraciones como una medida final de seguridad global de la entidad, aunque su configuración robusta ayuda, como ya se ha dicho, a mejorar las protecciones globales.

Autor: Diego Samuel Espitia Montenegro
Chief Security Ambassador – CSA (Colombia) @ElevenPaths

¿Es difícil suplantar tu dirección de correo electrónico? #Spoofing #Pentesting #Python

El e-mail spoofing es una técnica muy antigua pero que sigue siendo muy utilizada en los esquemas de ataque de Spear Phishing o Spear Apps para engañar a un usuario haciéndole creer que está recibiendo un correo electrónico de una persona concreta, cuando esto no es así. Es decir, un usuario suplanta la identidad de otro e intenta hacer un mensaje lo más creíble posible. En muchos procesos de hacking ético se debe llevar a cabo este tipo de pruebas para verificar varias cosas, por ejemplo que un conjunto de empleados están concienciados y no caerán ante este tipo de práctica, aunque en algunas ocasiones es muy difícil no caer, y, por otro lado, verificar la correcta configuración de mecanismos de atenuación como SPF (Sender Policy Framework)/SenderID, DKIM (Domain Keys Idetified Mail) o DMARC (Domain-based Message Authentication, Reporting and Conformance), aunque la única solución efectiva es que todos los empleados utilicen sistemas de firma digital como SMIME o PGP.

Figura 1: ¿Es difícil suplantar tu dirección de correo electrónico?

Hoy os hablaré de un par de herramientas escritas en Python que pueden ser utilizadas en nuestros procesos de Ethical Hacking y que permiten comprobar si un dominio es spoofeable y, por lo tanto, se puede enviar un correo electrónico falso que permita engañar a la víctima. De este par de herramientas la que realmente me ha sido más útil, quizá por sencillez es la de SpoofCheck. Esta herramienta permite verificar una serie de condiciones para demostrar si un dominio es spoofeable o no, tal y como lo hacemos nosotros en las auditorías de seguridad persistentes que hacemos con Faast. Es decir, la herramienta nos dirá si el dominio que se quiere suplantar es, probablemente, spoofeable o, si por el contrario, deberíamos buscar otro tipo de vía como usar nombres parecidos. Por otro lado, la herramienta SimpleEmailSpoofer es un script escrito en Python que se encarga de conectar con un servidor SMTP Postfix local y llevar a cabo el envío del e-mail, con los parámetros y atributos que le indiquemos a la aplicación. Instalación

La instalación o descarga de estas aplicaciones es muy sencilla. Directamente se pueden obtener desde sus repositorios de Github. Una vez descargadas ambas herramientas con el comando git clone, por ejemplo, se debe instalar las dependencias que éstas tienen. La ejecución del comando pip install –r requirements.txt se debe llevar a cabo.

SpoofCheck

¿Cuándo un dominio es spoofeable? La herramienta SpoofCheck se encarga de ir comprobando una serie de condiciones. A continuación podemos ver las condiciones que se evalúan para verificar si un dominio es spoofeable o no:

• Ausencia del registro SPF o DMARC.
• El registro SPF del DNS del dominio no especifica ~all o –all.
• La política DMARC está configurada a p=none o no existe.

Viendo estas condiciones vamos a realizar algunas pruebas con dominios conocidos. En el primer ejemplo vamos a analizar apple.com. Como se puede ver en la siguiente imagen Apple dispone de un registro SPF habilitado y con política –all. Sin embargo, aunque existe registro DMARC, la política no se encuentra específica, por lo que dicho dominio es potencialmente spoofeable. Apple ha mejorado su política, pues cuando sucedió el Celebgate, el dominio tenía la política ~all, lo que lo hacía más fácil aún de suplantar.

Figura 2: Verificación del dominio Apple.com

Como segundo ejemplo vamos a realizar un análisis de Gmail y Outlook, como ejemplo de proveedores de correo electrónico gratuito más utilizados en el mundo. Tal y como se puede ver en la imagen ambos tienen de registro SPF, dónde se incluyen las direcciones IP o dominios que son utilizados por los servidores de correo electrónico autorizados. Ambos disponen de DMARC pero sin política aplicada, por lo que la aplicación SpoofCheck nos devuelve que son dominios potencialmente spoofeables.

Figura 3: Verificación de gmail.com y outlook.com

Para el caso de Paypal observamos una grata diferencia. No es spoofeable debido a que dispone de registro SPF con direcciones IP especificadas. Dispone de registro DMARC y, además, tiene una política de rechazo habilitada.

Figura 4: Verificación de Paypal.com

Hay que recordar que Paypal tiene otros pequeños errores o debilidades, como la posibilidad de robar cuentas por el fallo del usuario al registrar un correo electrónico no real al crear su cuenta de Paypal.

SimpleEmailSpoofer

La herramienta SimpleEmailSpoofer es muy sencilla de configurar y ejecutar. Lo primero de todo es disponer de un archivo en el incluyamos el código HTML del body del correo. Para el ejemplo que se muestra a continuación se ha realizado un pequeño ejemplo de un correo de Apple. En el body se puede ver la carga de una imagen, la cual es la manzana de Apple.

Figura 5: Envío del correo spoofeado

Una vez generado el fichero se deben utilizar una serie de parámetros para poder enviar el correo electrónico. Antes de poder utilizar SimpleEmailSpoofer hay que estar seguros de Postfix se encuentra instalado en el sistema. En caso de no estar instalado, se debe ejecutar apt-get install postfix, y posteriormente service postfix start.

Figura 6: correo electrónico generado

Se utilizan diferentes parámetros para indicar el archivo con el body del mensaje, la dirección de e-mail a la que enviaremos el correo electrónico, la dirección de remitente que se quiere spoofear y el nombre del usuario que envía el correo electrónico. Por último, el parámetro –j nos permite indicar el asunto con el que se enviará el correo. Si vemos el correo electrónico que nos llega vemos como podría pasar perfectamente por un correo real.

En conclusión, un par de herramientas útiles y que hay que tener en la mochila para nuestras auditorias y hacking éticos. Sobre todo herramientas como SpoofCheck, la cual permite inferir si un dominio será spoofeable y ver si tendremos éxito o no con la manipulación y creación de un correo electrónico falso en nuestra auditoria.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”