Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 3

Seguimos con el Análisis de captura de correo entrante IMAP, STARTTLS e IMAP IDLE que incicimos ya aquí:

Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 1.

Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 2.

Vimos que era IMAP, las diferencias con POP, modos de funcionamiento, estados de una sesión IMAP, palabras clave como CAPABILITY, LOGIN, STARTTLS, IMAP IDLE, EXAMINE, SELECT, FETCH. También las distintas respuestas del servidor centrándonos en la respuesta del servidor a SELECT y FETCH.


Wireshark Tshark IMAP en Seguridad y Redes.  sesión telnet IMAP. LIST.

En esta ocasión vamos a ver las órdenenes del cliente y respuestas del servidor relativas a gestiones como listado (LIST y LSUB), creación y borrado de carpetas, borrado de mensajes. También veremos otras formas de autenticación y LOGIN y realizaremos una sesión telnet al servidor IMAP para ver las disintas formas se argumentar las órdenes o comandos y respuestas fallidas (BAD) del servidor. Otros comandos que vamos a ver son MYRIGHTS, GETACL y GETQUOTAROOT.

Para ello vamos a estudiar otra captura IMAP. En otra máquina y desde un cliente y versión diferente de software. Veremos la diferencias respecto a la captura de la Parte 1 y 2 de esta serie dedicada a IMAP. Veremos como el LOGIN ya no se realiza en texto plano a pesar de no tener activada la opción STARTTLS, etc, etc.

La captura sobre la que trabajaremos la he editado para su mejor comprensión:

Wireshark Tshark IMAP en Seguridad y Redes.

Voy a descartar en extenderme en explicaciones referentes a paquetes y son similares la las anteriores capturas.

Paquetes del 1 al 3. 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.

Paquete 4. Respuesta servidor a inición conexión TCP con éste . También lo hemos visto.

Paquete 6. Petición de capacidades soportadas por el servidor. En este caso vemos que el Request Tag es 1 y no 0001 como en las anteriores capturas.

Paquete 7. Respuesta servidor anunciando las capcidades sioportadas.

Paquete 8. Comando AUTHENTICATE. El cliente indica al Servidor el tipo de autenticación con el. En este caso AUTHENTICATE PLAIN (simple en texto plano). Sin embargo veremos que no es exáctamente así. La auntenticación se realizará con codificación Base64. Esta autenticación se realizará usando SASL que es un framework para autenticación y autorización en protocolos de internet.

El Request Tag es 2.

Paquete 9. El servidor responde con el carácter “+“. Esto significa que está pidiendo al Cliente que envíe usuario y contraseña.

Paquete 10.  El cliente envia la contraseña codificada en Base64:

AHNlZ3VyaWRhZHlyZWRlc0BzZWd1cmlkYWR5cmVkZXMuZXMAMTIzNDU=

Si usamos un decoder Base64, online hay muchos, veremos que obtenemos sin mayor problema:  seguridadyredes@seguridadyredes.es 12345

Paquete 11. Seguimos con el mismo Request tag y el Servidor responde con OK a la atuteticación del Cliente con el Servidor.

Paquete 12. LSUB. Palabra clave o comando que indica al Servidor el listado de buzones activos o suscritos. Bajo argumentos se indica también los criterios de búsqueda. En este caso:

Wireshark Tshark IMAP en Seguridad y Redes. LSUB

Como argumento, LSUB tiene aquí la cadena “” que significa que el nombre del buzón se interpreta como un SELECT, por ejemplo (SELECT INBOX). El comodín “*” equivale a un patrón que acepta 0 ó más caracteres en dicha posición. El Request tag es 3.

Paquete 13. Respuesta del Servidor al comando LSUB anterior. Request Tag es 3. En este caso:

Response: * LSUB () “/” “INBOX”

  • () lista vacía
  • “/” constructor de jerarquías. a partir de donde se listará o dará información de buzones.
  • “INBOX” nombre buzón devuelto

La lista de buzones:

Wireshark Tshark IMAP en Seguridad y Redes. LSUB respuesta response

Obaservad la última parte. Respuesta OK de servidor. Comando completado e información de Request Tag: 3

Paquete 14. Comando LIST, que devuelve un subconjunto de nombres de buzón dentro de un buzón de referencia. En este caso la petición es sobre el buzón INBOX y sin salir de el. Pero podríamos ver todos los buzones o solo los buzones que “cuelgan” de INBOX. Lo vemos iniciando una sesión telnet al puerto 143 del Servidor IMAP:


Wireshark Tshark IMAP en Seguridad y Redes. sesión telnet IMAP. LIST.

Observad como he probocado un error ( respuesta BAD del Servidor ). En este caso ha ocurrido por no indicar el Request Tag.  Al poner el valor 1 al primer comando introducido (CAPABILITY), entonces la respuesta del Servidor es OK.

A continuación indicamos el tipo de autenticación. Vemos en la respuesta a la petición ce capacidades del servidor que los tipo/métodos de autenticación son:

  • AUTH=CRAM-MD5
  • AUTH=PLAIN
  • AUTH=LOGIN
  • AUTH=DIGEST-MD5
  • AUTH=NTLM
  • STARTTLS

En esta sesión usamos AUTH PLAIN. Responde el servidor pidiendo usuario/contraseña en Base64. Si el usuario y contraseña lo indicamos en texto plano, el servidor devuelve un NO como error, no de sintaxis, sino de que el comando está correcto pero no el argumento o información dada.

Lo que nos interesa. El comando LIST. Está marcado con azul y observad como, dependiendo de la forma que indiquemos los argumentos, el servidor los dará una respuesta u otra. En este caso:

  • Request tag 3: solo información nombre buzón INBOX 3 list “” “INBOX”
  • Request tag 4: todos las buzones desde la raiz 4 list “” *
  • Request tag 5: solo los buzones que “cuelgan” de INBOX 5 list “INBOX” *

3 list “” “INBOX”
* LIST () “/” “INBOX”
3 OK LIST completed
4 list “” *
* LIST () “/” “INBOX”
* LIST () “/” “INBOX/Alfon”
* LIST () “/” “INBOX/Alfon/Otros”
* LIST () “/” “INBOX/Trabajo”
* LIST () “/” “Borrador”
* LIST () “/” “Deleted Items”
* LIST () “/” “Drafts”
* LIST () “/” “Elementos enviados”
* LIST () “/” “Junk E-mail”
* LIST () “/” “Projects”
* LIST () “/” “Proveedores”
* LIST () “/” “Sent Items”
* LIST () “/” “Trash”
4 OK LIST completed
5 list “INBOX” *
* LIST () “/” “INBOX/Alfon”
* LIST () “/” “INBOX/Alfon/Otros”
* LIST () “/” “INBOX/Trabajo”
5 OK LIST completed

Paquete 16. Comando SELECT enviado por Cliente al Servidor. Ya lo hemos visto anteriormente.

Paquete 17. Respuesta del Servidor al comando SELECT. Ya lo hemos visto anteriormente. Lo repasamos porque en este caso hay ligeras diferencias:

Wireshark Tshark IMAP en Seguridad y Redes. sesión telnet IMAP. select

Aquí vemos que la respuesta contiene información de

  • FLAGS banderas o indicadores informando del estado.  Ejemplo de algunas banderas:
    • \Seen El mensaje ha sido leído
      \Answered Mensaje contestado
      \Flagged El mensaje está marcado por urgencia y de atención especial
      \Deleted El mensaje tiene la marca o bandera de “borrado”. Se eliminaría definitivamente (PURGE) con la orden o palabra clave EXPUGNE.
      \Draft  El mensaje no ha completado no se haterminado de escribir, está marcado como borrador.
      \Recent Mensaje que acaba de ser recibido justo en esta sesión.

  • 3 EXISTS 3 mensajes en INBOX
  • 0 RECENT ninguno reciente
  • OK UIDVALIDITY…. Valor de vigencia de identificador único para control de sesiones.
  • OK UIDNEXT 4… Valor de UID que serrá asignado al primer mernsaje nuevo que llegue a INBOX.
  • OK PERMANENTFLAGS…. Indica al cliente cual de las banderas conocidas pueden ser cambiadas de manera permanente.
  • OK READWRITE… SELECT COMPLETE Selección de modo Lectura-Escritura. Éxito en la operación comletada.

Paquete 18. Comando MYRIGHTS. Petición por parte del Cliente para pedir información sobre los derechos (permisos) que posee el usuario de la cuenta sobre el buzón,en este caso, INBOX. Request tag 6.

Paquete 19.
Devuelve información sobre los derechos del usuario sobre INBOX:

Response: * MYRIGHTS “INBOX” “lrswicdaO

El Request tag es 6.

Paquete 20. Comando GETACL. Petición por parte del Cliente para pedir información sobre la lista de control de acceso de INBOX. Request tag 6.

Paquete 21. Respuesta del Servidor a la petición GETACL:

Response: * ACL “INBOX” “seguridadyredes@seguridadyredes.es” “lrswicdaO

Paquete 22. Comando GETQUOTAROOT. Petición por parte del cliente al Servidor sobre la obención de información para cuota del buzón indicado para el usuario de correo. En este caso no se establecieron cuotas al crear el usuario. Veremos en el siguiente paquete cual sería la información si se hubiese establewcido algún tipo de cuota. Request tag es 8.

Paquete 23. Respuesta del Servidor a la petición GETQUOTAROOT. La información no esimportantepuesto que no se establecieron cuotas. Pero, de haberse establecido la información devuelta sería:

Wireshark Tshark IMAP en Seguridad y Redes. GETQUOTAROOT RESPUESTA RESPONSE

La información devuelta es STORAGE 560 1024 MESSAGE 7 25. Esto significa que se estableció para el usuario seguridadyredes una cuota de 1 GB de espacio, ocupando ahora 560 MB. También se estableció como cuota de límite de mensajes la cantisdad de 25, ahora hay 7.

El Request Tag es 8.

====================================

Otras partes de esta serie:

Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 1.

Wireshark / Tshark. Análisis correo entrante IMAP. STARTTLS e IMAP IDLE. Parte 2.

=======================================

Y esto es por hoy.  En el siguiente capítulo más.

Esta entrada fue publicada en Seguridad y redes, Wireshark . Tshark. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s