El rincón de JMACOE

1. CORREO ELECTRÓNICO

Hoy en día, todas las empresas tienen su propio servidor de correo electrónico, basado en el anticuado e inseguro protocolo SMTP. Básicamente, lo que pasa cuando mandas un mail desde tu cuenta de correo, origen@origen.es, hasta una cuenta de destino, destino@destino.es, es lo siguiente:

• Tu agente de correo local envía el mail a tu servidor de correo saliente.
• El servidor de correo saliente busca el MX (servidor de correo) del dominio al que mandas el mail.
• Tu servidor de correo se conecta al puerto 25/TCP del MX de destino y le transmite los datos.

Por supuesto, dado que siempre nuestros empresas van a tener un servidor de correo, éste va a ser un buen punto para empezar con el tema de la seguridad.

Si bien es cierto que existen mecanismos más que suficientes para verificar el origen y la integridad de un correo electrónico, también es cierto que no están implementadas en la práctica. Raro es que alguien use criptografía en su correo electrónico, incluídos directivos de la empresa y personal de seguridad informática. Raro es también que se intente verificar el origen del mail, pese a la existencia de los SPF records y a la posibilidad de verificar que quien manda un mail desde eduardo@miempresa.es realmente lo hace desde la IP de un servidor de correo de miempresa.es.

Sí, es raro.

El SMTP permite por tanto declarar como origen del mail LO QUE NOS DE LA GANA. Y esta es una de sus grandes «debilidades».

3. ESTABLECIENDO UNA SESIÓN DE CORREO VÍA TELNET

Lo primero será averiguar cuál es el servidor de correo de nuestro objetivo, para ello ejecutamos dig @80.58.0.33 destino.es mx, que pide el servidor MX (mail) del dominio destino.es al dns de telefónica 80.58.0.33.

Ahora podemos hacer lo mismo que hace nuestro servidor de correo haciendo telnet al puerto 25 del MX de destino. Enviar un mail «a mano» es tan sencillo como esto:

Como podéis ver, hemos establecido una sesión de telnet al puerto 25 y hemos hecho uso de los comandos del protocolo SMTP para enviar nuestro mail. Del mismo modo, podríamos enviar un mail con un documento adjunto o cualquier otra cosa. La ventaja de hacer esto así, es que nos permite verificar que ciertos comandos han sido deshabilitados … o no …

4. VULNERABILIDADES COMUNES

1. Lo primero que miramos es el banner del servidor de correo, que usamos para ver si existe alguna vulnerabilidad publicada … Si es así, ya sabes qué tienes que hacer. Lo normal es que el banner haya sido modificado, pero en el caso de que el servidor sea sendmail esto requiere recompilar el código, con lo que es posible que no lo hayan cambiado. En lugar de ver el banner, también podemos usar amap (http://freeworld.thc.org/thc-amap/) o nmap, como sigue: amap -sT -d -b -o amap.out 192.168.1.100 25

1. Ahora miramos es si el servidor de correo es un open relay. Es decir, si permite enviar mails a otros destinos que no sean de su dominio. Para ello, simplemente nos conectamos por telnet y vemos el resultado de meterle en «RCPT TO» una dirección de gmail o cualquier otra cosa.

1. Después, vemos si los comandos «vrfy» y «expn» están habilitados. No deberían, ya que el primero puede usarse para verificar si existe un mail dado, lo cual permite sacar todos los usuarios de correo por fuerza bruta, y el segundo «expande» una dirección de mail, ofreciendo valiosa información sobre el destinatario. Debería de darnos un error.

1. Ahora, intentamos ver si entra un mail con «FROM:» de la propia empresa. Si es así, es posible que lo que enviemos desde una dirección falsa de la propia empresa no sea escaneado por el filtro antivirus/antispam.

1. Otra prueba que podemos hacer es enviar un virus como documento adjunto en un rar cifrado. Los filtros antivirus tienen un tiempo máximo asignado a escanear los adjuntos. Intentan descifrarlo y si no pueden ponen el archivo en cuarentena. Si este tiempo no está bien puesto, podemos tirar el servidor mail mandando un montón de pequeños .rar. Un DOS simple y efectivo, que es fácil que funcione.

1. Y seguimos con nuestros intentos … ¿tienen puesto un tamaño máximo para los adjuntos? Compruébalo. Mándales un pedazo de adjunto de 30Mb, a ver qué pasa …

1. Ahora, intentaremos algo que suele ser bastante efectivo: vamos a comprobar si existen direcciones de correo genéricas para toda la empresa, a lo mejor está definido como alias algo tipo «empleados», «todos», «empresa», «sistemas», «comunicaciones», «rrhh», … Haz una lista e intenta a ver si llegan. Si es así, podemos mandarles SPAM o ficheros adjuntos pesados hasta aburrirnos.

1. Y también podemos recopilar direcciones de correo usadas por la empresa … Ya sabes, google …. Además, si hemos conseguido enumerar direcciones de correo de la empresa podemos hacerlas públicas (posteándolas en cualquier foro de rusia o ucrania, por poner un ejemplo) para que reciban abundante SPAM.

Por cierto, cuando haces un «dig» para preguntar cuáles son los servidores de correo de una empresa … cuida al de menor prioridad. Es posible que esté mal configurado o desactualizado. Algunos administradores declaran un servidor falso, que no existe pese a estar declarado en el DNS (esto es posible, ver el RFC correspondiente) para despistar a los spammers.

5. CONCLUSIÓN.

El correo electrónico es uno de los posibles puntos débiles de la empresa. En este artículo, hemos visto unos cuantos posibles ataques al protocolo SMTP, totalmente basados en el funcionamiento del protocolo y configuraciones incorrectas, que pueden ser llevados a cabo facilmente de forma anónima y de los que debemos estas prevenidos.