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.
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:
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:
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:
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:
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:
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:
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.
Seguridad y Redes 