Recientemente decidí probar la herramienta Fraude del CEO en un dominio propio. Confiado de que mi proveedor contaba con todas las medidas de seguridad, ejecuté la prueba sin más. El resultado dio positivo, lo cual, en principio, significó que un atacante podría haber enviado un correo en nombre de cualquier persona a otra persona dentro de la organización. Por ejemplo: yo podría recibir un correo electrónico de mi jefe (ejemplo: mijefe@nuestrodominio.com) pidiéndome que realice una transferencia de una cierta cantidad de dinero a una determinada cuenta bancaria, sin haber sido realmente mi jefe, pero ¡utilizando exáctamente su dirección de correo electrónico!
Ante la situación, me contacté con mi proveedor de servicio de correo y volví a comprobar la seguridad provista: IP Blocklist, Reputation, Rate Limits, Filtros Anti-spam, software Antimalware de última generación e incluso SPF, DKIM y DMARC correctamente configurados. ¿Cómo puede ser que seguía siendo vulnerable a estos ataques, a pesar de tener implantadas, aparentemente, todas las medidas técnicas para evitarlos?
Un artículo publicado en el Blog hace algunas semanas, explica cómo hacen spoofing a un dominio que posee SPF, DKIM y DMARC correctamente configurados. Habiéndolo leído, intuí que podría faltar alguna configuración de seguridad en el servidor de envío de correos de mi organización, que impidiera que cualquier persona desde afuera pudiera utilizarlo para enviar mensajes entre cuentas de correo mi dominio.
Es así que realicé la siguiente prueba para comprobar si esto era posible. Comparto el instructivo para que quienes lo deseen lo apliquen.
¿Cómo comprobar si pueden suplantar mi identidad por correo electrónico?
Importante: existen múltiples vulnerabilidades en un servidor de correo que pueden ser explotadas con el fin de suplantar identidades, ésta es sólo una de ellas, muchas veces descuidada por nuestros proveedores, con graves consecuencias.
Requisitos
- Sistema Operativo: Windows 10.
- Aplicación para conectarnos al servidor SMTP: Cliente Telnet (debe estar instalado y habilitado). Algunas consideraciones:
- Los comandos telnet no diferencian mayúsculas de minúsculas.
- No se puede usar la tecla “backspace” en la sesión de Telnet.
- Si se comete un error al escribir comandos SMTP, presionar entrar y, a continuación, volver a escribir el comando. De otra forma se mostrará un error como el siguiente: 500 5.3.3 Unrecognized command.
- Puerto TCP del servidor SMTP: suele ser 25, 465 o 587. Este es el puerto TCP a través del cual el servidor SMTP recibe las solicitudes.
Instructivo
Buscamos el nombre del servidor responsable de enviar los correos de la organización que utiliza el protocolo SMTP. Para ello necesitamos el nombre del dominio. Por ejemplo si estaorganizacion.com sabemos que tiene servidor de envío de correo asociado (usamos cuentas como nombre@estaorganizacion.com), entonces podemos averiguar cuál es ese servidor introduciendo el dominio en la herramienta mxtoolbox.
Supongamos que es mx-1.estaorganizacion.com.
Una vez que obtenemos el nombre del servidor SMTP, abrimos la consola “Símbolo del sistema” y nos conectamos al servidor encargado del envío del correo a través de la aplicación Telnet.
1) Clic en “ Inicio”.
2) Tecleamos en el buscador cmd, luego “ Enter”.
3) En la consola tecleamos: telnet mx-1.estaorganizacion.com 25
4) Introducimos nuestros datos luego del comando telnet. En este caso, el nombre del servidor de correo que obtuvimos en el punto 1 y el puerto.
5) Tecleamos “ Enter”.
6) Se va a volver a limpiar la ventana mostrando en la parte superior algo parecido a: 220 host.red.local Microsoft ESMTP MAIL Service ready at Thu, 21 Nov 2019 13:05:52 +0100
Una vez conectados, vemos al cursor que parpadea para empezar a escribir comandos. A continuación le brindamos instrucciones al servidor para que envíe un correo, escribiendo.
7) EHLO estaorganizacion.com
8) Tecleamos “ Enter”.
9) Saludamos al servidor de correo y obtenemos una lista de palabras clave para indicar las extensiones soportadas. Debería mostrar algo como:
250-host.red.local Hello [85.52.230.99]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XRDST
10) MAIL FROM:<nicolas@estaorganizacion.com>
Aquí escribimos el nombre de la persona y el dominio que deseamos que aparezca en el remitente del correo electrónico que llegará al destinatario. Yo, como atacante, estaría suplantando la identidad de Nicolás, el CEO de estaorganizacion.
11) Tecleamos “ Enter”. Debería mostrar algo similar a: 250 2.1.0 Sender OK.
12) RCPT TO: <virginia@estaorganizacion.com>. Aquí escribimos la dirección del destinatario de nuestro correo. Yo, como atacante, quiero que lo reciba Virginia, la CFO de estaorganizacion.com.
13) Tecleamos “ Enter”. Debería mostrar algo similar a: 250 2.1.5 Recipient OK.
14) DATA. Tecleamos “ Enter”. Debería mostrar algo similar a: 354 Start mail input; end with <CRLF>.<CRLF>
15) Subject: URGENTE Transferencia.
Escribimos el texto del asunto (siempre se escribe “ Subject: “ y a continuación el mensaje que deseamos. Tecleamos “ Enter” 2 veces.
16) Hola Virginia, necesito que transfieras 2000 euros a la cuenta 12987391. Lo necesito para hoy, sino no podremos incorporar a la nueva pasante. Gracias.
Escribimos el cuerpo del mensaje. Podemos dar “ Enter” para saltos de línea todas las veces que queramos. Una vez que terminamos tecleamos “Enter”, luego un punto (.) y luego “Enter” para cerrar el mensaje. Deberíamos recibir como respuesta algo similar a:
250 2.6.0 <e4030bf5-a0e5-4ef0-be7d-80e0b90a4588@HOST .red.local> [InternalId=29862907609751, Hostname=HOST .red.local] 1701 bytes in 20.701, 0,080 KB/sec Queuedmail for delivery
17) QUIT. Tecleamos “ Enter” para salir del sistema. Debería mostrar algo similar a: 221 2.0.0 Service closing transmission channel
Posibles resultados
Cuando ejecuté esta prueba, enviando un correo electrónico a mi casilla a nombre de alguien más de la organización, lo recibí en la bandeja de entrada sin ningún problema. Esto significa que alguien podría haber hecho lo mismo desde cualquier aplicación posible (no sólo Telnet), dado que mi servidor SMTP permitía conexiones anónimas (sin autenticar).
Por suerte, el servidor de correo no estaba configurado como Open Relay, lo que me hubiera permitido enviar un correo electrónico hacia cualquier dirección fuera de estaorganizacion.com. Open Relay permitiría que otros pudieran enviar SPAM utilizando mi servidor de correo, lo cual podría hacer que me lo baneen.
Luego comprobé que era posible suplantar la identidad de quien deseara, incluso de cualquier usuario de Google, Yahoo Mail, etc. Esto tiene sentido, ya que el correo electrónico es enviado desde el mismo servidor de estaorganización y, por lo tanto, no realiza ninguna comprobación de seguridad como SPF, DKIM o DMARC.
El inconveniente de los controles técnicos
Cuando una organización decide llevar a cabo acciones en materia de seguridad de la información, en general se enfoca en implementar medidas de seguridad técnicas en equipos informáticos o para proteger los mismos. Dichas medidas, por sí solas traen los siguientes inconvenientes:
- No cubren todo el alcance y pueden resultar muy costosas. A saber, por más que implementemos una docena de ellas, nunca llegan a cubrir todo el alcance (IoT, Cloud, dispositivos, etc.), sumado a que se incurre en costos altísimos.
- Pueden ser fácilmente omitidas. Podríamos poseer toda la tecnología de vanguardia en ciberseguridad administrada por expertos, para proteger nuestros sistemas, pero los ciberdelincuentes utilizarán otros métodos, como la ingeniería social, para atacarnos sin tener que enfrentar dichas barreras.
A su vez, podríamos contar con los mejores especialistas en las tecnologías y servicios que brinda el área TIC a la organización para tratar de garantizar configuraciones correctas y seguras desde el punto de vista técnico, pero siempre habrá errores u omisiones.
Un ejemplo es el caso analizado, donde la vulnerabilidad está en que el protocolo SMTP no requiere autenticación para su implementación, permitiendo a un atacante realizar las acciones demostradas. Además, si se utilizara esta vulnerabilidad para lanzar un ataque de ingeniería social (como el expuesto), que no involucra ningún archivo o enlace con código malicioso, las medidas de seguridad no tendrían ninguna posibilidad de detenerlo.
Soluciones y conclusiones
Por lo tanto, para poder defendernos de este y cualquier otro tipo de ataque similar es necesario adoptar un esquema de defensa en profundidad incorporando medidas de seguridad de la información técnicas y físicas pero sin olvidar los controles administrativos, generalmente descuidados, como son la implantación de políticas internas y la concienciación a los usuarios que garantice un cambio positivo en su comportamiento.
Actualmente, casi nadie se ocupa de que el usuario en contacto con la tecnología posea un perfil mínimo necesario para responder correctamente ante las amenazas de seguridad dirigidas hacia la organización.
A continuación detallo algunas de las pautas que debería incluir la formación a usuarios para no caer en una trampa similar a la analizada:
- Utilizar la opción “Reenviar” y no “Responder” en caso de tener que responder un correo electrónico. Al reenviar el correo electrónico, la dirección correcta debe escribirse o seleccionarse manualmente desde la libreta de direcciones. Muchas veces al utilizar la opción “responder” creemos que estamos haciéndolo al remitente original cuando en realidad está programado para enviárselo al atacante.
- No compartir información en exceso de manera pública. Se debe tener cuidado con lo que se publica en las redes sociales y en los sitios web de la organización, especialmente todo lo referido a tareas y descripciones de puesto, información jerárquica y detalles de horarios (ejemplo: fuera de la oficina). Además, cuantas más cuentas de correo corporativas tenga expuestas en Internet, más susceptible es su organización a un ataque de Spear Phishing (phishing dirigido). Se puede comprobar qué direcciones de email están publicadas en internet a través de esta herramienta.
- Confirmar solicitudes críticas de múltiples formas. Establecer un procedimiento para que los empleados confirmen de otras maneras las solicitudes hechas por correo electrónico para una transferencia bancaria o información confidencial. Por ejemplo, cara a cara o mediante una llamada telefónica utilizando números previamente conocidos, no números telefónicos proporcionados por correo electrónico.
- Conocer los hábitos de los empleados, clientes y proveedores. Por ejemplo, tener cuidado si hay un cambio repentino en las prácticas o procesos comerciales o personales. Si un contacto comercial pide repentinamente que use su dirección de correo electrónico personal cuando toda la correspondencia anterior ha sido a través del correo electrónico de la empresa, la solicitud podría ser fraudulenta. Siempre verificar la solicitud a través de una fuente diferente.
Deja un comentario