Muchos de mis usuarios recibieron correos electrónicos de docs#@mydomain.com (donde docs # estaba entre docs0 y docs8 o algo así, y mydomain.com obviamente cambió de mi nombre de dominio real), con el nombre del remitente de "Administrator . " El mensaje tenía el asunto "Nuevo mensaje de voz" y el mensaje: "Recibió un mensaje de correo de voz. La longitud del mensaje es 00:06:11". Fue enviado a muchos usuarios y grupos de distribución diferentes, una combinación extraña de departamentos diferentes que normalmente no tendrían sentido (correo electrónico a nuestro grupo de servicio al cliente, más nuestro CFO, más un miembro de TI aleatorio? Extraño). Había un archivo adjunto: ATT00001..txt, un archivo de texto.
Algunas investigaciones en línea muestran que se trata de un intento de virus posiblemente de CryptoLocker (¡gracias!), y el archivo de texto restante es lo que quedaba después de ser eliminado a la llegada, ya sea por nuestro servicio de filtrado de correo no deseado (no creo Por lo tanto, según los registros), nuestra puerta de enlace de SonicWALL (creo que es esto lo que nos salvó), o un escáner de virus integrado en Outlook (no, el correo web muestra el mismo archivo adjunto). Usamos Postini para nuestro servicio de filtrado de correo no deseado, por lo que nuestro MX registra todo el correo electrónico allí y nuestro servidor proxy Squid solo acepta el correo de Postini, realiza un filtrado y lo pasa a nuestro servidor de Exchange.
Sobre la base del encabezado del correo electrónico, he descubierto esta ruta que supuestamente tomó el correo electrónico (el dominio y nuestra IP pública han sido modificados):
docs9718.mydomain.com (10.139.106.94) - > smtp.mydomain.com (10.0.0.18)
docs844.mydomain.com (10.0.0.18) - > mydomain.com (10.0.0.147)
ABTS-KK-dynamic-175.185.172.122.airtelbroadband.in ([122.172.185.175]) - > exprod5mx283.postini.com ([64.18.4.10])
psmtp.com (exprod5mx283.postini.com [64.18.0.107]) - > proxy2.mydomain.com
proxy2.mydomain.com ([127.0.0.1]) - > localhost (proxy2.mydomain.com [127.0.0.1])
localhost (localhost.localdomain [127.0.0.1]) - > proxy2.mydomain.com
proxy2.mydomain.com (12.7.13.46) - > proteus.mydomain.com (192.168.200.3)
Postini estaba permitiendo que pasaran estos mensajes, aunque había un par de cosas extrañas sobre ellos. Por ejemplo, el ID de mensaje SMTP es una cadena única establecida por el primer servidor de mensajes que maneja el mensaje, y normalmente no es un problema para ningún servidor posterior. Sin embargo, el ID de mensaje de este correo electrónico era [email protected] en lugar de, por ejemplo, si obtuve algo de Dell, diría [email protected]. Tiene mi dominio en su ID de mensaje.
¡Pero fue entonces cuando me di cuenta de que los primeros servidores que manejaban el mensaje tenían mi nombre de dominio! Así es como se suplantó el SMTP Message-ID, supongo. De hecho, esa dirección residencial en India (ABTS-KK-dynamic ...) es probablemente un usuario doméstico con un virus, y ese virus formó las primeras direcciones.
El problema es que las direcciones 10.xxx no solo están en el rango de IP de ARPA privado, sino que obviamente no corresponden a nuestro dominio (modificado, pero en este ejemplo mi IP "real" es 12.7.13.46) . Otro problema es que hay una brecha entre el falso mydomain.com y la computadora india.
¿Cómo nuestros servidores de correo no dan cuenta de una brecha importante en los encabezados? ¿Y no verifica nada sobre el servidor de origen, solo toma su palabra? Debido a que no solo no es una IP válida, no coincide con los registros de DNS para el dominio que dice, sino que el dominio de origen es el mismo que el dominio de destino. Eso normalmente no tendría sentido, ya que ese correo sería interno.
Además, ¿tengo razón sobre esta técnica de suplantación de ID de mensaje SMTP? No puedo encontrar nada igual en línea. Pero la táctica tiene sentido: si digo que provino de algunos servidores falsos de mydomain.com y los servidores intermedios nunca verifican eso, el servidor final creerá que realmente proviene de mi dominio. Simple MAIL FROM: la suplantación de identidad en un relé abierto no funcionará en nuestro servidor, pero aparentemente algo así puede funcionar. Simplemente no estoy seguro de si eso es lo que se está haciendo aquí.
Aquí está el archivo completo de encabezados falsos (nombre público IP, dominio y A: direcciones de correo electrónico solamente): enlace de Pastebin