Aunque gurús varios llevan años vaticinando su muerte, el correo electrónico sigue manteniendo a día de hoy una salud de hierro, siendo parte fundamental de la operativa de muchas empresas. Y dado el uso omnipresente del mismo, es prácticamente imposible imponer cambio global alguno al funcionamiento del protocolo SMTP (diseñado hace décadas para que fuera robusto, no seguro).
Es por ello por lo que los atacantes siguen viendo el correo electrónico como un camino perfecto para penetrar en una empresa, ya que es un vector de ataque sencillo, dirigido y muy efectivo. En muchas empresas existen unos controles de seguridad básicos con respecto al servidor de correo electrónico, pero a día de hoy esos controles son insuficientes para detener ataques sofisticados.
Veamos dos ejemplos modernos de correos maliciosos empleados tanto por grupos de APT como por ransomware:
- Correo con un enlace malicioso: El usuario recibe un correo en el que se le anima a abrir un enlace externo. En dicha URL le espera un exploit kit para aprovechar una vulnerabilidad en el equipo e infectarlo.
- Correo con macros maliciosas: El usuario recibe un correo con un fichero de Office que contiene una macro maliciosa, que al ejecutarse realiza acciones no deseadas para el usuario.
En el primero de los casos el correo no contiene nada malicioso, por lo que el antivirus del servidor lo va a dejar pasar sin problemas en la práctica totalidad de los casos. En el caso de la macro maliciosa, cualquier malware medianamente sofisticado es capaz de ofuscar el contenido de una macro de forma que pueda evitar el antivirus y llegar al buzón del usuario.
En ambos casos, la última barrera termina siendo el usuario, que es el que pincha en el enlace o habilita la ejecución de las macros. Y, si bien la concienciación en seguridad es un aspecto crítico (y el autor es un firme defensor del concepto de “human firewall”), en el caso de ataques sofisticados los usuarios están en desventaja.
Algunos ataques de spear-phishing están tan bien diseñados que son materialmente imparables. Veamos un ejemplo de estos ataques tan bien preparados:
- Dirección de origen: El origen del correo está falsificado, siendo siempre alguien relacionado con la organización o incluso conocido (por ejemplo, en el caso de una empresa que exporte a Europa, un directivo de un proveedor de otro país).
- Asunto del mensaje: Los asuntos suelen ser siempre atractivos, intentando llamar la atención del usuario y con un cierto sentido de novedad y urgencia.
- Contenido: Aquí es donde el atacante pone toda la carne en el asador. Los atacantes sofisticados envían correos bien escritos (no hay faltas de ortografía ni traducciones baratas) y con contexto para el usuario, incitándolos a abrir el mensaje y/o adjunto.
Un ataque de spear-phishing bien preparado y ejecutado tiene una alta tasa de éxito, sobre todo en usuarios no preparados. Se pueden ver ejemplos de este tipo de ataques en los que sufrió el partido demócrata a manos de APT28, o en las últimas oleadas de ransomware de Endesa (que, si bien a día de hoy ya son muy conocidas, causaron estragos en sus primeros ataques junto con las de Correos).
El riesgo de este tipo de ataques es obvio, por lo que es necesario desplegar medidas que permitan mitigar el riesgo. Podemos dividir las medidas en dos tipos según su lugar de aplicación: servidor de correo o puesto de usuario.
[Nota: Estas medidas de seguridad no son en ningún caso las únicas a aplicar, debiéndose siempre tomar como un añadido a las ya existentes]
Medidas de seguridad en el servidor de correo
Para que un correo llegue al usuario antes tiene que pasar por el servidor de correo, que en estos casos es el punto de control en el que tendremos que aplicar nuestras medidas de seguridad. Los controles son muy similares a los de las aduanas de cualquier país, y se basan en dos preguntas muy concretas: ¿de dónde viene el correo? y ¿qué lleva dentro?
RBL (Real-Time BlackHole Lists)
La primera pregunta es importante ya que en muchos casos los correos son enviados desde dominios/IP que ya se conocen como maliciosos. Una primera línea de defensa muy eficaz pasa por usar RBL, también conocidas como DNSBL (DNS Blackhole Lists). Una RBL es un conjunto de listas negras de dominios e IP conocidos como maliciosos que puede ser consultada en tiempo real por un servidor de correo. Su funcionamiento es a grandes rasgos el siguiente:
- El servidor de correo recibe una conexión desde una IP determinada, e (opcional) intenta una resolución inversa DNS para obtener el nombre de dominio asociado.
- Con ambos datos, realiza una petición DNS contra el servidor que alberga la RBL.
- Si el dominio/IP está en la lista negra, el servidor devolverá una respuesta afirmativa. Si no está en la lista negra, devolverá un error.
- El servidor podrá rechazar directamente la conexión sin que el correo llegue a recibirse, o podrá redirigirlo a una cuarentena especial para su revisión.
El uso de RBL está muy extendido, ya que su consumo de recursos es muy escaso y su eficacia en la protección ante ataques masivos es muy elevada. Algunas RBL muy conocidas son SpamHaus o SpamCop, aunque existe una comparación semanal de muchas otras aquí.
SPF (Sender Policy Framework)
Si bien las RBL son capaces de filtrar ataques masivos, en el caso de un ataque dirigido la cosa cambia, ya que los atacantes van a hacer uso de dominios/IP totalmente inocuos que van a esquivar con facilidad estos filtros.
Los atacantes, sin embargo, van a querer falsificar la dirección de origen para maximizar las probabilidades de engañar al destinatario (no es lo mismo un correo recibido desde mariano.rajoy@presidencia.gob.es que con origen rajoy@evil.com). Realizar esta falsificación es muy sencillo, por lo que las probabilidades de éxito son muy altas.
Para solventar este problema podemos habilitar en nuestro servidor de correo la validación SPF. SPF es una tecnología pasiva que se aplica sobre SMTP y no modifica en ningún caso a los correos que recibimos. Su funcionamiento es muy sencillo:
- El servidor de correo recibe una conexión desde una dirección IP para entregar un correo.
- El servidor obtiene la dirección origen de las cabeceras del correo, y extrae el dominio del que dicho correo dice provenir.
- Se realiza una consulta DNS en la que el servidor de correo pregunta qué direcciones IP o dominios están autorizadas a enviar correo en el dominio extraído en el paso anterior.
- El servidor compara el valor obtenido de la consulta DNS con el del que ha realizado la conexión en primer paso. Si son distintos la validación SPF falla y el correo puede ser descartado o movido a una cuarentena.
Veamos un ejemplo aplicado al caso anterior. Supongamos que un atacante quiere enviar un correo con el origen falsificado para que, saliendo desde el dominio evil.com, el origen parezca provenir de la dirección de correo electrónico mariano.rajoy@presidencia.gob.es. Esto es lo que pasaría en un servidor con la validación SPF habilitada:
- El servidor recibe una conexión desde la IP 192.22.74.179
- El servidor lee las cabeceras del correo y extrae el dominio presidencia.gob.es
- Se realiza la petición DNS a presidencia.gob.es pidiendo su registro SPF y obteniendo como respuesta:
v=spf1 mx –all
Esta respuesta se interpreta de la forma siguiente: Solo están autorizados a enviar correo en mi nombre los registros MX de mi dominio, y nadie más. En este caso el servidor de correo haría una nueva petición DNS preguntando por los servidores de correo y obtendría esta respuesta:
mx0.presidencia.gob.es. 3600 IN A 212.128.110.200
mx1.presidencia.gob.es. 3600 IN A 212.128.110.207
mx2.presidencia.gob.es. 3600 IN A 212.128.110.208
mx3.presidencia.gob.es. 3600 IN A 212.128.110.200 - El servidor compara el valor 192.220.74.179 con los anteriores y no encuentra ninguna coincidencia, por lo que denegaría la entrega del correo a su destinatario.
Es importante reseñar que la configuración SPF de nuestro dominio y que se valide SPF en el servidor de correo son dos cosas distintas (se puede tener el registro SPF para que terceros validen nuestros correos, pero no validar nosotros los que nos llegan).
Dado que es una herramienta muy potente para detectar correos falsificados, se recomienda configurar el registro SPF propio para que terceros puedan dar validez a nuestros correos, así como habilitar la validación SPF en nuestro servidor (existen múltiples implementaciones para los servidores de correo más usado).
La configuración de nuestro registro SPF es tan sencilla como colocar en un registro DNS de tipo TXT las direcciones IP o dominios que están habilitados para enviar correo. Es crítico que este registro sea correcto, ya que en caso contrario aquellas organizaciones que validen SPF van a denegar de forma sistemática nuestros correos.
Se aconseja tener mucho cuidado sobre todo en aquellas organizaciones que envíen correos a través de terceros (por ejemplo, campañas de email marketing a través de servicios como MailChimp o similares), ya que tendrán que añadirlas a su registro SPF obligatoriamente. Es posible validar la configuración SPF a través de diversos servicios online.
En cuanto a la validación SPF, se recomienda su habilitación pero también de forma cuidadosa, ya que es posible que se produzca bloqueos indeseados debido a una mala configuración de SPF en el origen.
Se recomienda comenzar el proceso haciendo que el servidor no rechace los mensajes, sino que deje un mensaje de advertencia en los logs. Tras revisar durante varios días que no se bloquean correos importantes, se puede habilitar la validación SPF con una política más restrictiva. Se recomienda no rechazar directamente estos mensajes sino redirigirlos a una cuarentena, así como su monitorización de forma periódica para evitar perder mensajes importantes.
En el artículo siguiente, continuaremos con más medidas de seguridad a aplicar en el servidor de correo.
La entrada Evitando anzuelos: Cómo luchar contra los ataques de spear-phishing (I) aparece primero en Security Art Work.
via Security Art Work http://ift.tt/2e4zP6v
No hay comentarios:
Publicar un comentario