ACRONIS: La configuración incorrecta de Microsoft Exchange abre la puerta a ataques de spoofing

El punto de entrada

En 2023, Microsoft anunció un cambio en la forma en que se gestiona el protocolo de autenticación DMARC en Microsoft Exchange. A pesar del aviso de Microsoft, muchos usuarios no han seguido sus recomendaciones para configurar las funciones de filtrado mejoradas, o quizá aún no son conscientes de dicho cambio. En consecuencia, los usuarios que no han configurado Microsoft Exchange de forma adecuada están ahora expuestos a ataques de spoofing (suplantación de identidad) del correo electrónico, lo que podría dar lugar a que sus correos electrónicos se vean comprometidos, o bien a que se produzcan fugas de datos, entre muchos otros problemas.

En torno al 36 % de todas las fugas de datos que se han producido en la UE y en EE. UU., se ha originado a raíz de ataques de phishing. Los mensajes de phishing suelen parecer proceder de fuentes legítimas, como «admin@micr0soft.com» o «Administrador de TI email@google.com«, y presentan líneas de asunto y contenido diseñados para captar la atención de los usuarios, como información sobre salarios, nóminas, etc.

En algunos casos, los atacantes pueden imitar las direcciones de correo electrónico para hacerles creer a las víctimas que el mensaje procede de una fuente de confianza, como «su_jefe@suempresa.com«. Como el cliente de correo electrónico reconoce que la dirección del remitente coincide con la de su jefe, puede mostrar automáticamente la foto de contacto asociada, lo que aumenta la percepción de legitimidad. Esto facilita mucho el objetivo de engañar a los usuarios para que realicen acciones perjudiciales, como introducir sus credenciales, ejecutar aplicaciones maliciosas o transferir dinero a una cuenta desconocida.

¿Qué protocolos se utilizan para protegernos del phishing?

DMARC, DKIM y SPF: protección de su correo electrónico frente al spoofing (suplantación de identidad)

Protocolo simple de transferencia de correo (SMTP) es un protocolo utilizado para enviar mensajes de correo electrónico. Se creó en 1982, sin tener en cuenta la seguridad del correo electrónico. Inicialmente, se esperaba que la seguridad se gestionara de otra forma. Hoy en día, el tráfico SMTP entre servidores de correo electrónico se puede cifrar y autenticar con el protocolo TLS. Sin embargo, el protocolo SMTP original no incluía ningún método de autenticación de correos electrónicos.

Dado que el correo electrónico sigue siendo un objetivo clave para las amenazas de seguridad, como el spam, el phishing y el spoofing (suplantación de identidad), se han desarrollado tres protocolos principales para mejorar la seguridad del correo electrónico:

1. Sender Policy Framework (SPF): este protocolo comprueba si un servidor de correo está autorizado para enviar mensajes de correo electrónico en un dominio concreto mediante DNS.
2. DomainKeys Identified Mail (DKIM): este protocolo permite firmar digitalmente los mensajes de correo electrónico, lo que demuestra que proceden de un servidor de correo autorizado. Las firmas DKIM ayudan a los proveedores de correo electrónico a verificar la autenticidad del dominio del remitente.
3. Domain-based Message Authentication, Reporting, and Conformance (DMARC): este protocolo determina cómo se deben gestionar los mensajes de correo electrónico que no superen las verificaciones de los protocolos SPF o DKIM. Además, ayuda a decidir qué medida tomar cuando la autenticidad de un correo electrónico no logre verificarse.

Ejemplo de un flujo de correo electrónico

1. Servidor A realiza una solicitud DNS para encontrar el servidor de MX (Mail Exchange) de ourcompany.com.
2. Servidor A envía un correo electrónico desde usuario@empresa.com a user2@ourcompany.com a través de uno de los servidores de MX (Servidor B).
3. Servidor B verifica el correo electrónico; para ello:
   • Comprueba si el correo electrónico procede de un servidor autorizado (verificación del protocolo SPF).
   • Se asegura de que el correo electrónico disponga de una firma DKIM válida.
   • Sigue las acciones especificadas según la directiva DMARC.

Por ejemplo, si el Servidor A no está incluido en los registros del protocolo SPF, si el mensaje de correo electrónico no dispone de ninguna firma DKIM o tiene una firma DKIM que no es válida, y si el dominio empresa.com tiene una directiva DMARC configurada como «Rechazar», entonces el Servidor B debería rechazar el mensaje de correo electrónico.

Si tenemos:

SPF:

ourcompany.com.            3600    IN      TXT     «v=spf1 mx -all»

MX:

ourcompany.com.            300     IN      MX      10 s1.ourcompany.com.
ourcompany.com.            300     IN      MX      10 s2.ourcompany.com.

DMARC:

_dmarc.ourcompany.com.     2861    IN      TXT     «v=DMARC1; p=reject; fo=1»

Cabría esperar que se rechacen todos los mensajes de correo electrónico que lleguen de fuentes que no estén incluidas en nuestros registros de MX.

Sin embargo, ¿qué ocurre si el servidor de destino está configurado para ignorar estas directivas? ¿Y si no es decisión suya (del administrador de MX)? ¿O qué ocurriría si usted tuviera otro servidor de Mail Exchange, pero no es consciente de ello y no sabe cómo funciona?

En los siguientes subapartados profundizaremos más sobre estas cuestiones.

Microsoft Exchange Online

Puede configurar y utilizar Exchange Online como servidor de correo. En este caso, no necesita servidores Exchange in situ ni protección antispam de terceros.

Si utiliza Exchange Online sin servidores in situ o un servidor de MX de un tercero, este escenario no se aplica en su caso. Este escenario abarca dos posibilidades:

• Usted cuenta con un entorno híbrido: si dispone de un servidor Exchange in situ que se comunica con sus servidores Exchange Online a través de conectores.
• Usted utiliza un servidor de MX de un tercero: si utiliza una solución de seguridad de correo electrónico o antispam de un tercero.

Servidor de MX de un tercero

Si su servidor de MX apunta al servidor de MX de un tercero, debería consultar este artículo de Microsoft para configurar su instancia de EXO.

Esto significa que, por ejemplo, en lugar de:

ourcompany.com.            300     IN      MX      10 ourcompany.protection.outlook.com

usted tendría:

ourcompany.com.            300     IN      MX      10 s1.ourcompany.com

Entorno híbrido

Puede encontrar un artículo completo sobre qué es un entorno híbrido y cómo se debe configurar aquí. Si no dispone de su propio servidor de MX y todo el tráfico pasa por *.protection.outlook.com, no habrá riesgo de abuso en la configuración.

No obstante, ¿qué pasaría si utiliza su propio servidor de MX? De forma predeterminada, el asistente de configuración híbrida creará algunos conectores estándar de entrada y salida para el intercambio de datos entre el servidor de Exchange Online y el servidor de Exchange in situ.

No he encontrado ninguna referencia al artículo sobre servidores de MX de terceros en la documentación sobre Exchange en entornos híbridos. No obstante, en la documentación sobre Transport Routing (Enrutamiento de transporte) pude encontrar la siguiente información con respecto a servidores de MX de terceros:

Si decide mantener su registro de MX apuntando a su organización in situ: todos los mensajes enviados a cualquier destinatario de cualquiera de las organizaciones se enrutarán primero a través de su organización in situ. Cualquier mensaje dirigido a un destinatario ubicado en Exchange Online se enrutará en primer lugar a través de su organización in situ, y después se entregará al destinatario en Exchange Online. Esta ruta puede ser útil para las organizaciones que tengan directivas de cumplimiento que requieran el análisis de una solución de registro en diario de los mensajes enviados desde la organización y hacia esta. Si elige esta opción, Exchange Online Protection no podrá analizar eficazmente los mensajes de spam.

¿Cuál es el problema?

El punto más importante que se debe tener en cuenta es que si el registro de MX del dominio del destinatario inquilino apuntara a una solución de seguridad de correo electrónico diferente que se encuentre por delante de Office 365, entonces Honor DMARC no se aplicaría.

Dado que usted utiliza servidores de MX que no son de Microsoft, todos los mensajes de correo electrónico se verificarán a través de este servidor de MX de terceros. Debería estar bien, ¿no?

Pues la verdad es que no. Si usted no ha configurado su organización de Exchange Online para que acepte exclusivamente el correo de su servicio de terceros, o si no ha activado las funciones de filtrado mejoradas para conectores, cualquier persona podría enviarle un mensaje de correo electrónico a través de ourcompany.protection.outlook.com o ourcompany.mail.protection.outlook.com, y se omitirá la verificación del protocolo DMARC (SPF y DKIM).

Conectores de entrada

Para comprender cómo funcionan los conectores de entrada, es necesario analizar sus configuraciones.

Entorno híbrido

Enabled                        : True
ConnectorType                  : OnPremises
ConnectorSource                : HybridWizard
Comment                        :
SenderIPAddresses              : {}
SenderDomains                  : {smtp:*;1}
TrustedOrganizations           : {}
ClientHostNames                : {}
AssociatedAcceptedDomains      : {}
RequireTls                     : True
RestrictDomainsToIPAddresses   : False
RestrictDomainsToCertificate   : False
TlsSenderCertificateName       : *.ourdomain.com

A continuación se irán indicando las partes importantes de esta configuración: ¿para qué servidores se utilizará este conector? Para cualquier dirección IP y cualquier dominio.

SenderIPAddresses              : {}
SenderDomains                  : {smtp:*;1}

¿Qué se debe hacer con las conexiones que no entren en el ámbito? Nada.

RestrictDomainsToIPAddresses   : False
RestrictDomainsToCertificate   : False

Esto significa que si solo tiene este tipo de conector, su servidor Exchange in situ no restringirá las conexiones a ourcompany.protection.outlook.com o ourcompany.mail.protection.outlook.com.

Y si echamos un vistazo a las notas de este artículo sobre servidores de MX de terceros, encontraremos la siguiente información importante:

Si ya dispone de un conector de entrada in situ para el mismo certificado o direcciones IP del remitente, deberá crear el conector de entrada de partner (los parámetros RestrictDomainsToCertificate y RestrictDomainsToIPAddresses solo se aplican a los conectores de partner). Los dos conectores pueden coexistir sin problemas.

Esto significa que, por defecto, nuestra configuración no es segura.

Detalles importantes sobre los conectores de partners

Si desea configurar conectores de entrada para un servidor de MX de terceros, puede utilizar PowerShell o la interfaz gráfica de usuario (GUI). Asimismo, puede utilizar dos tipos de autenticación: por «dominio del remitente» o por «IP».

Si tiene un conector de partner con SenderIPAddresses : {} y, por ejemplo, un conector de partner con autenticación por «dominio del remitente», todas las conexiones (excepto las direcciones IP de los conectores en los que se haya configurado esta dirección específica) pasarán por este conector.

Si crea un conector de partner con autenticación por «IP» y con RestrictDomainsToIPAddresses, se bloquearán todas las conexiones «sin» conectores.

Si intenta crear un conector a través de la interfaz gráfica de usuario (GUI), no podrá establecer RestrictDomainsToIPAddresses en aquellos casos en los que se utilice la «IP» para la autenticación, ya que no existe la opción «Rechazar mensajes de correo electrónico si no se envían desde este intervalo de direcciones IP». Esto solo se puede hacer a través de PowerShell. O bien, debería utilizar la autenticación por «dominio del remitente».

Y marque la casilla «Rechazar mensajes de correo electrónico si no se envían desde este intervalo de direcciones IP».

¿Cómo puede protegerse?

Refuerzo

Si tiene un servidor de MX de un tercero, debería configurar al menos un conector de entrada adicional siguiendo las recomendaciones de Microsoft.

En el caso de entornos híbridos, debe crear un conector de partner con la misma IP o con el mismo certificado que se utilice en el conector in situ, como se indica a continuación:

New-InboundConnector -Name «Reject mail not routed through MX (third-party service name)» -ConnectorType Partner -SenderDomains * -RestrictDomainsToCertificate $true -TlsSenderCertificateName *.{domain.com} -RequireTls $true

o bien

New-InboundConnector -Name «Reject mail not routed through MX (third-party service name)» -ConnectorType Partner -SenderDomains * -RestrictDomainsToIPAddresses $true -SenderIpAddresses <#static list of on-premises IPs or IP ranges of the third-party service>

Además, puede implementar:

• Funciones de filtrado mejoradas para conectores en Exchange Online.
• Prevención de pérdida de datos (DLP).
• Reglas de transporte, como por ejemplo, para eliminar todos los mensajes de correo electrónico que no procedan de sus servidores de MX.

Prueba de concepto (POC)

Puede utilizar el código que se muestra a continuación para comprobarlo.

Importante:

• El parámetro «TO» es una dirección real. La dirección de correo electrónico debe existir en el lado de Exchange Online si no utiliza un esquema híbrido.
• El parámetro «Server» que puede obtener del resultado de las solicitudes es el siguiente:

dig yourdomain.onmicrosoft.com

o bien

dig yourdomain.mail.onmicrosoft.com

Ejemplo de código de PowerShell:

$from=»user1@yourdomain.com»
$to = «user2@yourdomain.com»
$server = «yourdomain.mail.protection.outlook.com»

$SMTPMessage = New-Object System.Net.Mail.MailMessage($from,$to)
$SMTPMessage.Subject = «Misconfiguration in the M365 tenant»
$SMTPMessage.Body = «From user@yourdomain.com»
$SMTPClient = New-Object Net.Mail.SmtpClient($server, 25)

try {
$SMTPClient.Send($SMTPMessage)
Write-Host (Get-Date).ToUniversalTime()
Write-Output «Email sent successfully to $to. From $from»
} catch [System.Net.Mail.SmtpException] {
Write-Host (Get-Date).ToUniversalTime()
Write-Output «SMTP Exception: $_»
} catch [System.Exception] {
Write-Host (Get-Date).ToUniversalTime()
Write-Output «General Exception: $_»
}

Las alertas y los eventos dependerán de su configuración