Ya vimos y estudiamos, en su momento, capturas para Tshark. Análisis correo saliente SMTP., en este caso vamos a hacer los mismo para IMAP.
Internet Message Access Protocol, o su acrónimo IMAP, es un protocolo de red de acceso a mensajes electrónicos almacenados en un servidor. Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para obtener correo desde un servidor. Por ejemplo, es posible especificar en IMAP carpetas del lado servidor. Por otro lado, es más complejo que POP ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP.
IMAP se basa en TCP y, por defecto, usa el puerto 143. Lo vemos…
- Actualizado: Se corrigen varias erratas ortográficas y se amplia en algunos aspectos.
- Actualizado: Se puntualiza sobre un aspecto de STARTTLS.
- Ya disponible la segunda parte: Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 2
Antes que nada…
Un poco de Teoría. El protocolo IMAP.
IMAP es un protocolo, al igual que POP, de acceso a mensajes de correo de un host o servidor remoto. Eso sí, algo más complejo que este.
Algunas características que identifica a IMAP y otras que lo diferencia de POP:
- Los mensajes se mantienen en el servidor, a los clientes solo se les envia una copia del mensaje.
- Acceso simultáneo a un mailbox de correo por parte de diferentes clientes.
- Se permite a los clientes realizar cambios estando conectados o no.
- Es posible descargar solo una parte del mensaje .
- Posibilidad de gestión de múltiples carpetas, creando estas o eliminando en el propio servidor.
- IMAP tiene varios modos de funcionamiento:
- offline El cliente se coencta de forma períodica y procede a descarga de mensajes.
- online El cliente gestiona mensajes directamente en Servidor.
- desconectado El Cliente se conectaa Servidor, gestiona localmente los mensajes, etc y peródicamente actualiza camvios conta Servidor.
- Estados de sesión IMAP. Representado en el Diagrama de flujos (más arriba):
- Not Authentificate State Estado no autentificado. Aún el cliente no se autentificó contra el servidor.
- Authentificated State Estado autentificado. El cliente ya ha sido autentificado por el servidor o proviene de un inicio de conexión pre-autentificado.Es momento de seleccionar un buzón del servidor y, de esta forma, acceder a los datos, es decir, a los mensajes.
- Select State Estado seleccionado. Pasada la fase anterior con éxito, ahora es el momento de operar con los mensajes de correo del buzón seleccionado.
- Logout State Estado logout. Cierre de conexión por alguna de las partes.
Para cada una de estas fases tenemos una serie de comentarios. Lo veremos a continuación.
El resto lo vemos estudiando las capturas.
Análisis captura sesión IMAP.
Partimos de la siguiente captura Wireshark ó Tshark, exportada a texto plano correspondiente a un servidor de pruebas y una cuenta creada a tal efecto:
La primera parte correspondiente a los paquetes 12,13 y 14 se refieren al inicio de la conexión entre el cliente y el servidor de correo al puerto 143 (IMAP).
Como ya hemos visto en varias ocasiones, una conexión TCP se realiza en tres pasos. Es lo que técnicamente se llama three-way handshake:
- En el sistema / host que inicia la conexión o cliente (TCP A), envía un paquete de SYN con un número de secuencia inicial asociado a esta conexión al sistema / host destinatario o servidor (TCP B).
- Este responde con un paquete SYN-ACK (acuse de recibo) confirmando la recepción del SYN inicial enviado por (TCP A) y enviándole a su vez su propio número de secuencia.
- Para finalizar, el cliente (TCP A) reconoce la recepción del SYN del servidor (TCP B) mediante el envío de un ACK. Este es el momento en que queda establecida la conexión. Ya se puede iniciar la transferencia de datos entre (TCP A) y (TCP B).
El paquete de respuesta 15, es la respuesta del Servidor indicando que está listo para iniciar la transmisión de datos e informando de la versión del servidor, etc.
El paquete 16, lo envía el Cliente y es una petición (Request) de lista de las capacidades o características soportadas por el servidor: 0000 CAPABILITY. No contiene parámetro alguno:
El Request Tag es una especie de prefijo identificador que genera el cliente por cada orden ó petición. A una misma petición el servidor puede enviar un paquete con la respuesta (Request) que sea conteniendo el mismo Request Tag.
El paquete 17 es la respuesta del Servidor a la petición (paquete 16) de capacidades soportadas. Dicha respuesta sería, en este caso:
* CAPABILITY IMAP4 IMAP4rev1 IDLE ACL LITERAL+ UIDPLUS QUOTA ID SORT ANNOTATE ANNOTATEMORE STATUS-COUNTERS UNSELECT LISTEXT STARTTLS AUTH=CRAM-MD5 AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=NTLM
0000 OK CAPABILITY completed
El paquete 18 es enviado por el cliente y se trata de una petición ó Request con el comando LOGIN. Envía información de la cuenta de usuario y contraseña. El Request Tag es ahora 0001. La información contenida es:
0001 LOGIN «seguridadyredes(at)seguridadyredes.es» «12345»
(NOTA: datos falseados )
Paquete 19. Es la respuesta del servidor a la petición de LOGIN. El Request tag es el mismo que el anterior: 0001.
0001 OK LOGIN completed
.
Cifrado de la conexión. Envio de datos cifrados protocolo IMAP.
Aquí habría que hacer un par de consideraciones. Como veis todo está en texto plano. Esto es así porque en el cliente de correo, al configurar la cuenta, no indicó, en seguridad de la conexión, el uso de, por ejemplo: STARTTLS para el cifrado de datos.
El comando STARTTLS no contiene ningún tipo de parámetro, e indica al Servidor la petición que realiza el Cliente de realizar la transmisión de datos de forma cifrada usando el protocolo TLS (Transport Layer Security).
De haberse realizado esto (STARTTLS) ,antes del LOGIN, habría un paquete en envía el host cliente al servidor del tipo Request:
Request: AVAST240 STARTTLS
NOTA: (AVAST240 tiene que ver con el escudo de protección de antivirus AVAST)
De no haber antiovirus con este tiupo de protección, la orden sería solo STARTTLS.
y una respuesta del Servidor:
Response: AVAST240 OK Ready to start TLS
A partir de ahí, todo iría cifrado.
Evidentemente lo recomendable es esto último.
Aquí vemos como sería la captura cifrada con STARTTLS activado:
Seguimos…
Vemos a continuación 4 paquetes desde el 20 al 23, conteniendo la palabra clave IDLE. IMAP IDLE es una extensión de IMAP. El objetivo es que el servidor avise al cliente de cuando ha llegado un correo y se sincronicen, esta sincronización se realiza de forma instantánea. Mientras el cliente está trabajando, gestionando el correo, enviando correos, será, en todo momento y de inmediato, notificado sobre nuevos mensajes.
Observad como, más arriba, en el paquete 17 he marcado la palabra IDLE en la respuesta del servidor a sus capacidades soportadas. Es, por tanto, una capacidad del servidor: el soporte IMAP IDLE.
.
A partir de aquí entramos en el estado de Authentificated State ó Estado autentificado (lo hemos visto más arriba). El primer comando que vemos en este estado es SELECT.
Con SELECT seleccionamos un determinado mailbox, indicado en la petición. Lo vemos en el paquete 24:
Vemos que la petición, por parte del Cliente, de selección de mailbox se realiza sobre la carpeta de entrada de correo INBOX para lectura y escritura. El valor de Request Tag es 0003.
Se podría haber usado otro comando: EXAMINE, pero el acceso a, por ejemplo INBOX, sería de solo Lectura.
El Servidor responde en el paquete 25 con una serie de FLAGS ó banderas y respuestas OK, en este caso:
* FLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1274868094] UID validity
* OK [UIDNEXT 2] Predicted next UID
* OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Draft \Flagged $MDNSent $Forwarded $AutoJunk $AutoNotJunk $Junk $NotJunk)] Permanent flags
0003 OK [READ-WRITE] SELECT completed
=======
Todo esto y el resto de la captura lo veremos en el próximo capítulo dedicado a IMAP. Habrá más capítulos a parte del segundo. Me quedan muchas cosas por contar.
Ya disponible la segunda parte:
Seguridad y Redes 
Pingback: Justniffer. Un sniffer que reensambla, reordena y muestras los flujos TCP. | Seguridad y Redes
HOLA! estaria muy interesada en tener el archivo de la captura para wireshark!!!! tengo que entregar un trabajo y este post es MUY interesante, pero mi profesor me exige la captura!!
gracias!!!