El correo electrónico que me envió está dirigido a [email protected]. ¿Cómo se hace esto?

Recientemente me enviaron un correo electrónico fraudulento, y por risas lo abrí para leerlo. Muy sencillo, y sin mucho esfuerzo.

Noté algo peculiar; Este correo electrónico no fue dirigido a mí. Al principio, sospeché un CC o un BCC, pero en ninguna parte tiene mi dirección en el correo. He proporcionado una imagen a continuación. ¿Cómo se hace esto?

Un mensaje de correo electrónico de Internet consta de dos partes. Podemos referirnos a ellos como el sobre y el mensaje de carga útil o simplemente mensaje .

El sobre tiene datos de enrutamiento: principalmente, esta es la dirección del remitente y una o más direcciones del destinatario.

El mensaje tiene el contenido del mensaje: línea de asunto, cuerpo del mensaje, archivos adjuntos, etc. También contiene información técnica, como Received:encabezados trace ( ), datos DKIM, etc. así como los que se muestran remitente y destinatario direcciones (lo que ves en el From, Toy Cclos campos en su cliente de correo).

Aquí está el quid de la cuestión: ¡ los dos no tienen que estar de acuerdo!

Un servidor de correo examinará los datos del sobre para determinar cómo enviar el mensaje. Por otro lado, con pocas excepciones, el mensaje en sí será tratado como solo datos. En particular, un servidor de correo con buen comportamiento no mira los campos To:y Cc:del mensaje en sí para determinar la lista de destinatarios, ni mira el From:campo para determinar la dirección del remitente.

Cuando redacta y envía un correo electrónico, su cliente de correo electrónico toma lo que ingresó en los campos Para, CC y CCO, y lo traduce en información de enrutamiento de sobres. Esto se realiza principalmente mediante la eliminación de los nombres completos (dejando solo las direcciones de correo electrónico), pero también puede implicar cosas como la reescritura de direcciones, la expansión de alias, etc. El resultado es una lista de direcciones de correo electrónico que se proporcionan al servidor de correo con el que su cliente de correo está hablando como la lista de destinatarios. Las listas Para y CC se guardan en el correo electrónico, pero el CCO no se pasa al servidor, lo que lo hace invisible para los destinatarios del mensaje. La dirección del remitente funciona de manera muy similar.

Cuando el mensaje llega a su destino final, los datos del sobre se descartan o se retienen en los encabezados detallados del mensaje. Esa es una parte de la razón por la cual Spittin 'IT solicitó los encabezados de mensajes completos en un comentario a su pregunta.

Además, con el correo electrónico de Internet, es posible hablar directamente con un servidor de correo y, por lo tanto, inyectar un mensaje que no coincida entre los datos del sobre y los datos del mensaje que un cliente de correo electrónico normal y de buen comportamiento no haría. dejarte componer. Además, los servidores de correo realizan diversos grados de verificación en la dirección del remitente que se les da en los datos del sobre; algunos apenas lo comprueban más allá de asegurarse de que sea una dirección de correo electrónico sintácticamente válida. El encabezado De de los datos del mensaje está sujeto a un escrutinio aún menor.

Dado que el cliente de correo electrónico receptor muestra lo que está en los encabezados From, To y Cc, no los datos de la dirección del sobre, es posible colocar allí lo que desee y el cliente de correo electrónico receptor no tendrá más remedio que confiar en que es razonablemente exacto Para el correo legítimo, generalmente es lo suficientemente preciso; para el spam, casi nunca lo es.

En el mundo de los objetos físicos tangibles habitados por nosotros, simples humanos, el remitente y el destinatario del sobre corresponden a la dirección del remitente y la dirección del destinatario, respectivamente, que usted escribe en el exterior del sobre; y los encabezados From:y To:/ Cc:corresponden a lo que haya puesto como dirección de usted y del destinatario, respectivamente, en la carta que ha incluido en el sobre.

tl; dr en la parte inferior.

El protocolo SMTP no tiene la noción de destinatarios CC o BCC; Esta es una convención celebrada por clientes de correo. El servidor SMTP generalmente solo se preocupa por la información y datos de enrutamiento. Esta es una distinción importante, porque sin esta capacidad, BCC no podría existir. Como comunicación legítima de BCC, considere la siguiente transcripción del cliente:

HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
BCC: "Anonymous" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Ahora, en este caso, Anonymous recibió un mensaje sobre esta reunión. Sin embargo, esta versión del correo no fue enrutada a Jane Doe; ella no sabe nada sobre Anonymous siendo notificado. Por el contrario, a Jane Doe se le enviará el mensaje con un cuerpo y encabezado diferentes:

HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Aquí, dado que Anonymous estaba en BCC, el mensaje enviado a Jane Doe no incluía la lista de destinatarios de BCC. Debido a la convención de BCC, el sobre del correo electrónico puede no incluir destinatarios que realmente recibieron el mensaje, y también puede incluir destinatarios que no aparecen en los encabezados del mensaje.

Como mencioné @JonasWielicki , que también quise incluir, es que el MUA (Agente de usuario de correo) generalmente es responsable de enviar los múltiples correos electrónicos necesarios para implementar BCC. Los servidores de correo electrónico no saben nada sobre BCC, por lo que el MUA debe implementar BCC enviando múltiples correos electrónicos con diferentes rutas de correo electrónico especificadas en los encabezados de los sobres. Por esta razón, los BCC suelen tardar más en enviarse que los correos electrónicos normales, ya que los diferentes cuerpos de mensajes deben construirse y enviarse individualmente.

Esto también ayuda con algunas reglas de cumplimiento de correo electrónico. Por ejemplo, un servidor de correo puede tener reglas configuradas para BCC automáticamente a un servidor de correo electrónico de archivo (todos los correos electrónicos que se le envían también se archivan), en cuyo caso el servidor de correo podría no ser un destinatario real.

HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
BCC: "Anonymous" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Aquí, el destinatario es otra parte que no se revela por completo a ninguno de los destinatarios o incluso al remitente. Esta es una característica del protocolo, que generalmente se usa para retransmitir o archivar mensajes.

Lo que hizo este mensaje de spam fue aprovechar ese comportamiento. Es una laguna estándar que técnicamente debería funcionar con cualquier servidor de correo compatible. Por supuesto, muchos servidores actualizados usan "extensiones" como DKIM para verificar que dicho correo electrónico sea auténtico, pero todavía hay muchos servidores de correo antiguos que no les importa, simplemente porque es tentador no arreglar cosas que no están rotas.

También tenga en cuenta cómo he especificado un encabezado de fecha. Esto puede ser cualquier valor arbitrario (pero bien formateado); muchos clientes mostrarán felizmente cualquier rango de fechas legales desde el pasado lejano hasta el futuro lejano. Personalmente, me envié un correo electrónico hace años que permanecerá en la parte superior de mi casilla de correo mucho después de mi expectativa de vida, así como un correo electrónico anterior a mi cuenta de correo electrónico y mi propio nacimiento.

tl; dr

Entonces, en resumen, el remitente falsificó un correo electrónico, el servidor de correo original lo aceptó / retransmitió, su servidor de correo electrónico lo aceptó y lo almacenó en su bandeja de entrada, y su cliente le mostró fielmente los datos que estaban en su bandeja de entrada, todo sin eludir Cualquier seguridad. La seguridad de "envío" a menudo es mucho menos restringida que la seguridad de "recepción" en esa perspectiva, ya que POP3 casi siempre requiere un nombre de usuario y una contraseña antes de poder acceder a un buzón de correo (teóricamente podría eludir esto, pero no sé de ningún legítimo servicios de correo que lo hacen).

SMTP y el correo electrónico son servicios de Internet muy antiguos de una era en la que la seguridad y la autenticación se tomaban mucho menos en serio (DNS es otro ejemplo). El diseño del protocolo no hace ningún esfuerzo por verificar la autenticidad de la dirección del remitente, y solo valida la dirección del destinatario en la medida en que se asegura de que el correo se pueda entregar.

El correo electrónico se transmite a través del protocolo SMTP. El protocolo SMTP es relativamente tonto; Proporciona una facilidad para transmitir texto sin formato a una dirección de correo electrónico y muy poco más. La estructura de este texto plano está definida por RFC 5322 . La idea general es que el texto del correo electrónico tiene metadatos llamados encabezado y el cuerpo del texto real del mensaje. Este encabezado de correo electrónico es generado por el remitente (no se puede confiar en ninguno de ellos) y contiene campos como "a:", "de:", "asunto:", etc.

El protocolo SMTP no valida (y no debe) validar que los encabezados de correo electrónico coincidan con algunas de las pocas cosas definidas en el protocolo SMTP, que son esencialmente su dirección de correo electrónico y una dirección de correo electrónico del remitente que nunca se valida de ninguna manera.

Casi todo en un mensaje de correo electrónico puede ser falso.

Lo único que hoy en día es remotamente confiable sobre el contenido del correo electrónico son las firmas DKIM, que prueban que el correo electrónico fue procesado a través de un servidor de correo electrónico autorizado por el registrante del dominio. Profundizando, encontrará que este correo electrónico fraudulento no tiene firma DKIM.

La dirección Toen el encabezado del correo electrónico tiene fines informativos y el cliente de correo electrónico la muestra. La dirección del destinatario real se proporciona RCPT TOen SMTP. Es lo mismo si escribe una carta, coloca un sobre, escribe la Dirección-1 en el sobre. Luego ve al servicio de mensajería, dale otra dirección-2. El servicio de mensajería coloca su sobre en un sobre más grande con la Dirección-2 y el envío irá allí. Su secretaria (software de cliente de correo electrónico) tira el sobre externo a la basura y le muestra el sobre interno con la Dirección-1. Puede ver esto con una vista RAW del mensaje de correo electrónico.

Este es un aspecto ligeramente diferente, basado en el examen de los encabezados. Las otras respuestas manejan los detalles de SMTP mejor que yo.

Si puede obtener los encabezados completos de su mensaje, luego busque su dirección, puede encontrarla en un campo llamado Envelope-to, Delivered-too X-Apparently-to. El primero es utilizado por mi proveedor de correo, el segundo por Gmail; También he visto el tercero usado. Estos son campos diferentes, pero para nuestros propósitos tienden a significar lo mismo: el buzón en el que realmente entrega el mensaje. Probé enviando desde Outlook (versión de escritorio) con el destinatario BCCed.

Mi proveedor de correo también usa el Delivered-Tocampo pero para el nombre del buzón en su servidor. Esta no es mi dirección de correo electrónico, aunque parece una (piense ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Outlook (combinado con Exchange Server), por otro lado, no incluye en los encabezados un solo campo con la dirección de correo electrónico del destinatario si aparece como BCC.