Tp 1 (SMTP Sniffing)

UNIVERSIDAD DE BUENOS AIRES
FACULTAD DE INGENIERIA
Seminario de Redes de Computadoras
Trabajo Práctico No1
Análisis de SMTP mediante sniffing
Baglivo Fabricio 80519
Garcia Cáceres David 75889
Docente: Utard Marcelo
Argentina
2007
Contents
1 Introducción
1.1 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
2 Desarrollo
5
3 Resultados
3.1 Caso 1
3.2 Caso 2
3.3 Caso 3
3.4 Caso 4
6
6
14
16
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66.48
1
Trabajo Práctico 1
Baglivo - Garcia Cáceres
Introducción
SMTP (Simple Mail Transfer Protocol) es un protocolo basado en texto utilizado para enviar correo electrónico. Se definió originalmente en el RFC
821, pero actualmente se utiliza lo que se conoce como ESMTP (Extended
SMTP), definido en el RFC 2821.
Este protocolo es de tipo cliente-servidor. Una aplicación de correo (Outlook,
Eudora, etc.) o un servidor tipo MTA (Mail Transfer Agent) pueden actuar
como cliente.
Cuando se utiliza una aplicación de correo, se debe configurar cuál es el servidor SMTP que se va a emplear. Al enviar un mail, la aplicación lo ”entrega”
al servidor SMTP, el cual buscará el registro DNS MX (Mail Exchange) de
cada destinatario y lo reenviará al servidor destino que corresponda. Es decir
que en este caso se están realizando varias transferencias, una entre la aplicación y el servidor SMTP, y una o varias (dependiendo de los destinatarios)
entre el servidor SMTP y los servidores destino.
Para realizar una transferencia, el cliente SMTP debe iniciar una conexión
TCP en el puerto 25 del servidor. Una vez establecida la conexión, comienza
la sesión SMTP propiamente dicha.
Durante la sesión, cliente y servidor intercambian comandos y respuestas
(Figura 1). Las respuestas pueden incluir un código numérico de tres dı́gitos
junto a un texto explicativo (Figura 2).
Figure 1:
En la actualidad, los clientes de correo inician las sesiones SMTP mediante el comando EHLO en lugar de HELO. Si el servidor responde, significa
que soporta ESMTP y sus extensiones. Si el cliente no recibe respuesta luego
de EHLO, interpreta que el servidor no soporta ESMTP y envı́a un HELO.
2
Figure 2:
En las respuestas del servidor que contienen números, el primer dı́gito
indica la categorı́a de la respuesta. Están definidas como indica la figura 2.
En el ejemplo de la figura 3 se observa claramente las distintas etapas
de la sesión: el saludo o presentación, el envı́o de la información del correo
electrónico (incluyendo remitente, destinatario y cuerpo del mensaje) y el
cierre de sesión. Se observa también cómo el servidor avisa que el destinatario
especificado en ”Cc:” no existe.
1.1
Seguridad
Una de las limitaciones del standard SMTP original es que no incluye un
mecanismo de autenticación del remitente, lo que favorece diversas prácticas
dańinas como el spam.
Para solucionar este inconveniente, se definió mediante la RFC 2554 la extensión SMTP-AUTH para el protocolo ESMTP. Esta extensión implementa,
entre otras cosas, autentificación del remitente mediante usuario y contraseńa.
Además, ambos son enviados al servidor codificados, lo que otorga mayor
nivel de seguridad. El mecanismo de codificación puede ser negociado entre
cliente y servidor.
En la figura 4 se puede ver un ejemplo del uso de AUTH.
Entre las lı́neas 2 y 5 del ejemplo se produce la solicitud de usuario y contraseńa por parte del servidor y el envı́o de estos datos por parte del cliente.
Una vez que el servidor comprueba la validez de la información, responde
que la autenticación ha sido correcta
Si bien el uso de estas extensiones evita que cualquier persona pueda enviar
correo utilizando direcciones de remitentes falsos (o incluso usando direcciones existentes que no le pertenecen), no es suficiente para solucionar el
problema del spam. Para esto hay varias propuestas, algunas que complementan al protocolo SMTP y otras que directamente lo reemplazan.
3
Figure 3:
Figure 4:
4
66.48
2
Trabajo Práctico 1
Baglivo - Garcia Cáceres
Desarrollo
Se planteó como objetivo monitorear la información intercambiada al enviar
correo electrónico mediante SMTP para lograr una visión global de todos los
protocolos implicados en una transferencia de este tipo.
Para esto, se armó una pequeńa red de dos PC’s y un router con conexión
a Internet (ver Figur 5) y se instaló un sniffer en una de las computadoras
para monitorear el tráfico de la red.
Figure 5: Topologı́a de la Red donde se realizó sniffing
Con este esquema, los pasos que se siguen cada vez que se envı́a un mail
son:
• Petición de MAC address del default gateway por parte de la PC
• Consulta DNS para saber la IP del servidor SMTP utilizado
• Establecimiento de la conexión TCP con el puerto 25 del servidor
• Sesión SMTP entre cliente y servidor
• Finalización de la conexión TCP
Para conocer la respuesta del sistema ante diferentes situaciones, se plantearon
cuatro casos de análisis, a saber:
5
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
• Envı́o de correo electrónico desde la PC1 utilizando el servidor SMTP
de Speedy, con todo configurado correctamente.
• Interrupción del enlace WAN durante el envı́o de un correo electrónico
como el del Caso 1.
• Envı́o de correo electrónico con una configuración errónea del servidor
SMTP en la aplicación de correo.
• Envı́o de correo electrónico teniendo mal configurado el default gateway
de la PC.
3
3.1
Resultados
Caso 1
En este caso, se configuraron todos los parámetros de red de forma adecuada y se envió un mail. A las PC’s se les configuró la IP del router
(192.168.0.1) como default gateway y se empleó el servidor SMTP de Speedy
(smtp.speedy.com.ar) para enviar el mail. Las capturas se hicieron utilizando
WireShark en la PC desde la que se enviaba el mail. Los resultados obtenidos
se uestran a continuación en la figura 6
Figure 6: Resultado de la captura en el caso 1
En la captura se pueden ver todos los pasos que se siguen cuando se hace
una sesión SMTP tı́pica. A continuación detallaremos cada paso
6
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
• Linea 1.ARP Request
Figure 7: ARP Request
La PC hace un ARP Request para averiguar la dirección MAC de la IP
192.168.0.1 que corresponde al router (que está configurado como default
gateway de la PC). Este paquete ARP Request contiene la IP de la PC, la
MAC de la PC y la IP de la cual se quiere conocer la MAC, y es enviado
como broadcast, como se puede ver en el campo Destination.
• Linea 2. ARP Replay
El router devuelve un ARP Reply con su dirección MAC (00:0e:4e:0a:19:39).
Este paquete no es broadcast, sino que está dirigido a la PC que hizo el ARP
Request (campo Destination).
• DNS Query
La PC hace un DNS Query para conocer la dirección IP del servidor
SMTP que tiene configurado, en este caso, smtp.speedy.com.ar. Se puede
7
Figure 8: ARP Replay
Figure 9: DNS Query
8
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
observar que si bien la dirección MAC especificada es la del router, la dirección IP es la del servidor DNS primario que tiene configurado la PC
(200.51.211.7). Esto se debe a que para llegar a esa dirección IP, que no
se encuentra en la red local, el paquete debe ser enviado al default gateway.
Notar que se está haciendo uso de UDP, como se esperaba. En la PC se usa
el puerto efı́mero 1048 y en el servidor el puerto 53 (exclusivo para DNS). En
la última lı́nea se observa también que se está solicitando un registro tipo A.
• DNS Response
El servidor DNS devuelve la IP asociada al servidor SMTP que se solicito
en el paso anterior (66.119.67.23). Se devuelven también los nombres de los
servidores autoritativos (dns2.advance.com.ar y dns1.advance.com.ar) y sus
direcciones IP (200.10.122.10 y 200.10.122.11).
Como en la Lı́nea anterior, se puede observar el uso de UDP.
Figure 10: DNS Response
• Establecimiento de la conexión TCP. Paso 1
La PC inicia una conexión TCP al puerto 25 del servidor SMTP enviando
un segmento SYN, que es el primer paso del 3-way handshake del protocolo
9
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
Figure 11: Establecimiento de la conexión TCP. Paso 1
TCP. En la captura se pueden ver, además de las direcciones MAC e IP
origen y destino, el puerto efı́mero de la PC (1283), el valor de Seq (0), el
Maximum Segment Size (MSS = 1460) y el tamańo de la ventana (65535).
• Establecimiento de la conexión TCP - Paso 2
El servidor SMTP responde al SYN enviado por la PC enviándole el Acknowledge correspondiente (Ack = 1), su número de secuencia (Seq = 0),
el tamańo máximo de segmento (MSS = 1452) y el tamańos de la ventana
(Win = 5840). Este serı́a el segundo paso del 3-way handshake.
Además de la información mencionada, también se pueden las direcciones
MAC e IP y los puertos origen y destino.
• Establecimiento de la conexión TCP - Paso 3
La PC devuelve un Acknowledge (Ack = 1) al servidor, finalizando los
tres pasos requeridos para estableces la conexión TCP.
10
Figure 12: Establecimiento de la conexión TCP. Paso 2
Figure 13: Establecimiento de la conexión TCP. Paso 3
11
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
• Lı́neas 8 a 35: Sesión SMTP
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
01 220 elimba.terra.com ESMTP
EHLO nuevita
250-elimba.terra.com
250-PIPELINING
250-SIZE 26214400
250-AUTH PLAIN LOGIN
250 8BITMIME
AUTH LOGIN
334 VXNlcm5hbWU6
aGJhZ2xpdm9Ac3BlZWR5LmNvbS5hcg==
334 UGFzc3dvcmQ6
MTIzNDU2
235 Authentication successful
MAIL FROM: <hbaglivo@speedy.com.ar>
250 Ok
RCPT TO: <baglivofabricio@gmail.com>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Message-ID: <000801c7f666$0abd3e60$0300a8c0@nuevita>
From: ”Hugo Baglivo”<hbaglivo@speedy.com.ar>
To: <baglivofabricio@gmail.com>
Subject: Prueba
Date: Thu, 13 Sep 2007 21:27:31 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
.boundary=”—-= NextPart 000 0005 01C7F64C.E48D95A0”
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
This is a multi-part message in MIME format.
——= NextPart 000 0005 01C7F64C.E48D95A0
Content-Type: text/plain;
.charset=”iso-8859-1”
Content-Transfer-Encoding: quoted-printable
Esta es una prueba
——= NextPart 000 0005 01C7F64C.E48D95A0
Content-Type: text/html;
12
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
40 .charset=”iso-8859-1”
41 Content-Transfer-Encoding: quoted-printable
42 <!DOCTYPE HTML PUBLIC ”-//W3C//DTD HTML 4.0 Transitional//EN”>
43 <HTML><HEAD>
44 <META http-equiv=3DContent-Type content=3D”text/html; =
45 charset=3Diso-8859-1”>
46 <META content=3D”MSHTML 6.00.2900.3157” name=3DGENERATOR>
47 <STYLE></STYLE>
48 </HEAD>
49 <BODY bgColor=3Dffffff>
50 </DIV><FONT face=3DArial size=3D2>Esta es una =
51 prueba</FONT></DIV></BODY>< /HT M L¿
52 − − − − − − = N extP art 000 0005 01C7F 64C.E48D95A0 − −
53.
54250Ok : queuedasBF 7CA1BC074
55QU IT
56221Bye
La sesión SMTP comienza cuando, una vez que se estableció la conexión
TCP, el servidor se presenta (Lı́nea 01). El cliente también se presenta mediante el comando EHLO (Lı́nea 02). Recordemos que este comando se usa
para que el servidor envı́e las extensiones ESMTP que soporta. Estas extensiones se encuentran entre las Lı́neas 03 y 07, y especifican, entre otros, que
soporta autenticación de usuario y MIME de 8 bits.
A continuación, comienza el proceso de autenticación encriptada (Lı́neas
08 a 13). En cliente envı́a su nombre de usuario (Lı́nea 10) y contraseńa
(Lı́nea 12) encriptados en respuesta a los pedidos del servidor (Lı́neas 09
y 11 respectivamente). En la Lı́nea 08, se puede apreciar además que el
cliente especifica el mecanismo de encriptación que va a usar (LOGIN). Esta
encriptación debe ser una de las extensiones que el servidor especificó que soportaba (Lı́nea 06). Una vez que el server verifica que el nombre de usuario y
contraseńa son correctos, devuelve un ”Authentication successful”. En caso
contrario, la sesión SMTP termina y cae la conexión TCP.
Una vez finalizadas la presentación y la autenticación, el cliente comienza
a enviar los datos del mail. En la Lı́nea 14 indica la dirección de mail de
origen y en la Lı́nea 16 la dirección de mail destino. Para cada uno el servidor responde un ”Ok” (Lı́neas 15 y 17). A continuación, el cliente indica
con ”DATA” que comienza el cuerpo del mensaje (Lı́nea 18) y el servidor le
responde que debe finalizarlo con una lı́nea que contenga solamente un punto
13
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
(Lı́nea 19).
Entre las Lı́neas 20 y 52, el cliente envı́a el cuerpo del mensaje, que contiene la dirección origen (Lı́nea 21), la dirección destino (Lı́nea 22), el Subject
(Lı́nea 23), la fecha y hora (Lı́nea 24) y el cuerpo propiamente dicho en formato MIME (Lı́neas 25 a 52).
En la Lı́nea 53, se envı́a una lı́nea que contiene solamente un punto, dando
ası́ por finalizado el envı́o de datos. El servidor responde con un ”Ok” y notificando que el mensaje a sido puesto en cola con un determinado número
hexadecimal (Lı́nea 54).
Concluida esto, el cliente podrı́a enviar otro mensaje, por lo que se repetirı́a lo sucedido entre las Lı́neas 14 y 54. En este caso, el cliente da por
finalizada la sesión enviando ”QUIT” (Lı́nea 55) y el servidor se despide
(Lı́nea 56).
• Lı́nea 36: Finalización de la conexión TCP
Figure 14: Finalización de la conexión TCP
Una vez que ha finalizado la sesión SMTP, se da de baja la conexión TCP
ente la PC y el servidor SMTP. Para esto, la PC envı́a el segmento FIN al
servidor. Como en los casos anteriores, se pueden observar en la captura los
valores de Ack, Seq, el tamańo de la ventana, etc.
3.2
Caso 2
• Interrupción del enlace WAN durante el envı́o del mail
14
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
Como en el caso anterior, se configuraron todos los parámetros de red de
forma adecuada y se envió un mail, pero se interrumpió intencionalmente la
conexión WAN mientras se realizaba la comunicación. Los resultados que se
obtuvieron fueron los que se muestran en la figra 15
Figure 15: Interrupción del enlace WAN durante el envı́o del mail
Podemos observar que la comunicación sigue los mismos pasos que en el
Caso 1, pero que en determinado momento (Lı́nea 38) se comienzan a generar
mensajes ICMP debido a la interrupción del enlace.
Figure 16: Interrupción del enlace WAN durante el envı́o del mail
La PC no recibe los acknowledge de los segmentos TCP enviados, por
lo que reenvı́a los segmentos. Por cada reenvı́o, recibe un mensaje ICMP
”Destination unreachable - Network unreachable” que le indica que no se
pudo entregar el segmento debido a que no se puede llegar a la red a la que
va dirigido. Luego de 5 retransmisiones, la PC da de baja la conexión TCP
15
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
enviando un segmento FIN al servidor (Lı́nea 55). Como era de esperar,
la PC recibió un nuevo mensaje ICMP ”Destination unreachable - Network
unreachable” ya que este segmento tampoco pudo ser entregado al servidor
destino.
Otro aspecto destacable es el tiempo que se espera entre cada retransmisión.
Recordemos que en TCP tenemos un timer que comienza a correr cada vez
que se envı́a un segmento. Si al finalizar el timer no se recibió el acknowledge correspondiente al segmento, se produce una retransmisión y el timer
es seteado a un valor mayor.
En este caso, podemos apreciar que el tiempo que transcurre entre la retransmisión de la Lı́nea 37 y la de la Lı́nea 39 es aproximadamente 2,2 segundos.
Entre la Lı́nea 39 y la 41 hay una demora de 4,5 segundos. Entre la Lı́nea
41 y la 43 hay 8,8 segundos, entre la 43 y la 45 hay 17,6 segundos y, entre la
45 y la 47, 30,7 segundos.
Se ve que cada tiempo de espera es aproximadamente el doble que el anterior,
lo que nos dice que el valor del timer es duplicado cada vez que el cliente
debe realizar una retransmisión.
3.3
Caso 3
• Configuración errónea del servidor SMTP
Como en el caso anterior, se configuraron todos los parámetros de red de
forma adecuada, pero se dejó mal configurado el nombre del servidor SMTP
(smtp.fibertel.com.ar en lugar de smtp.speedy.com.ar). Al enviar un mail
obtuvimos los resultados que se muestran en la figura 17
El proceso comienza de manera similar al Caso 1 y 2. Se producen los
ARP Request y Reply y el DNS Query. Como el servidor SMTP especificado
es erróneo pero existe, la PC recibe un DNS Response indicándole una dirección IP, la cual será utilizada para realizar la conexión TCP subsiguiente.
Todo el proceso se desarrolla de manera habitual hasta que el cliente se debe
autenticar ante el servidor SMTP. Para esto, envı́a su usuario y contraseńa
(Lı́neas 24 a 28), pero estos datos no son válidos para el servidor de Fibertel,
sino para el de Speedy. Como consecuencia de esto, la autenticación falla y
el servidor comunica esta situación al cliente mediante un ”Authentication
Failed” (Lı́nea 30).
A continuación, tanto el servidor como el cliente dan de baja la conexión
TCP y cada uno envı́a un segmento TCP FIN (Lı́neas 31 y 32).
16
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
Figure 17:
3.4
Caso 4
• Default Gateway mal configurado
Se configuraron todos los parámetros de manera adecuada a excepción del
default gateway. En la PC 1 (192.168.0.10) se seteó como default gateway la
dirección IP de la PC 2 (192.168.0.2). Se intentó enviar un correo con la PC
1 y se realizó sniffing en ambas PC’s.
Se muestran los resultados de la PC1 en la figura 18
Figure 18:
En este caso, el problema surge cuando la PC 1 hace la consulta DNS
17
66.48
Trabajo Práctico 1
Baglivo - Garcia Cáceres
para averiguar la dirección IP del servidor SMTP. Como la dirección del
servidor DNS no está en la red local, se envı́a el paquete con el DNS Query
a la dirección del default gateway. Aunque no quedó en la imagen tomada
de la captura, se pudo observar que los DNS Queries tenı́an como IP destino
las direcciones IP de los servidores DNS y como MAC destino la dirección
MAC de la PC 2.
En conclusión, los DNS Queries llegan a la PC 2, que descarta los paquetes sin realizar ninguna acción. La PC 1 sigue enviando DNS Queries a
las direcciones de los servidores DNS primario y secundario que tiene configuradas, pero nunca recibe una respuesta, por lo que el intento de enviar
el mail finaliza. No se genera ningún mensaje ICMP, ya que los paquetes
son descartados por la PC 2, por lo que no serı́a esperable que se produzcan
ICMP’s de tipo ”Destination unreachable”.
El sniffing en la PC 2 dio los resultados de la figura 19
Figure 19:
Al analizar la PC 2, se pueden observar los siete DNS Queries recibidos
desde la PC 1. Como la IP destino no es la de la PC 2, ésta descarta los
paquetes directamente. Este comportamiento es similar a cuando tenemos
varias PC’s conectadas mediante un hub; todas las PC’s reciben los paquetes
y determinan si son o no las destinatarias del mensaje analizando el campo
IP Destination. Tampoco es esperable que la PC 2 reenvı́e los paquetes a su
default gateway, ya que el ruteo de paquetes es función de un router y no de
un host.
18