IMAP/POP3
IMAP / POP3
With the help of the Internet Message Access Protocol (IMAP), access to emails from a mail server is possible. Unlike the Post Office Protocol (POP3), IMAP allows online management of emails directly on the server and supports folder structures. Thus, it is a network protocol for the online management of emails on a remote server. The protocol is client-server-based and allows synchronization of a local email client with the mailbox on the server, providing a kind of network file system for emails, allowing problem-free synchronization across several independent clients. POP3, on the other hand, does not have the same functionality as IMAP, and it only provides listing, retrieving, and deleting emails as functions at the email server. Therefore, protocols such as IMAP must be used for additional functionalities such as hierarchical mailboxes directly at the mail server, access to multiple mailboxes during a session, and preselection of emails.
Clients access these structures online and can create local copies. Even across several clients, this results in a uniform database. Emails remain on the server until they are deleted. IMAP is text-based and has extended functions, such as browsing emails directly on the server. It is also possible for several users to access the email server simultaneously. Without an active connection to the server, managing emails is impossible. However, some clients offer an offline mode with a local copy of the mailbox. The client synchronizes all offline local changes when a connection is reestablished.
The client establishes the connection to the server via port 143. For communication, it uses text-based commands in ASCII format. Several commands can be sent in succession without waiting for confirmation from the server. Later confirmations from the server can be assigned to the individual commands using the identifiers sent along with the commands. Immediately after the connection is established, the user is authenticated by user name and password to the server. Access to the desired mailbox is only possible after successful authentication.
SMTP is usually used to send emails. By copying sent emails into an IMAP folder, all clients have access to all sent mails, regardless of the computer from which they were sent. Another advantage of the Internet Message Access Protocol is creating personal folders and folder structures in the mailbox. This feature makes the mailbox clearer and easier to manage. However, the storage space requirement on the email server increases.
Without further measures, IMAP works unencrypted and transmits commands, emails, or usernames and passwords in plain text. Many email servers require establishing an encrypted IMAP session to ensure greater security in email traffic and prevent unauthorized access to mailboxes. SSL/TLS is usually used for this purpose. Depending on the method and implementation used, the encrypted connection uses the standard port 143 or an alternative port such as 993.
Default Configuration
Both IMAP and POP3 have a large number of configuration options, making it difficult to deep dive into each component in more detail. If you wish to examine these protocol configurations deeper, we recommend creating a VM locally and install the two packages dovecot-imapd, and dovecot-pop3d using apt and play around with the configurations and experiment.
In the documentation of Dovecot, we can find the individual core settings and service configuration options that can be utilized for our experiments. However, let us look at the list of commands and see how we can directly interact and communicate with IMAP and POP3 using the command line.
IMAP Commands
Command
Description
1 LOGIN username password
User's login.
1 LIST "" *
Lists all directories.
1 CREATE "INBOX"
Creates a mailbox with a specified name.
1 DELETE "INBOX"
Deletes a mailbox.
1 RENAME "ToRead" "Important"
Renames a mailbox.
1 LSUB "" *
Returns a subset of names from the set of names that the User has declared as being active or subscribed.
1 SELECT INBOX
Selects a mailbox so that messages in the mailbox can be accessed.
1 UNSELECT INBOX
Exits the selected mailbox.
1 FETCH <ID> all
Retrieves data associated with a message in the mailbox.
1 CLOSE
Removes all messages with the Deleted flag set.
1 LOGOUT
Closes the connection with the IMAP server.
POP3 Commands
Command
Description
USER username
Identifies the user.
PASS password
Authentication of the user using its password.
STAT
Requests the number of saved emails from the server.
LIST
Requests from the server the number and size of all emails.
RETR id
Requests the server to deliver the requested email by ID.
DELE id
Requests the server to delete the requested email by ID.
CAPA
Requests the server to display the server capabilities.
RSET
Requests the server to reset the transmitted information.
QUIT
Closes the connection with the POP3 server.
Dangerous Settings
Nevertheless, configuration options that were improperly configured could allow us to obtain more information, such as debugging the executed commands on the service or logging in as anonymous, similar to the FTP service. Most companies use third-party email providers such as Google, Microsoft, and many others. However, some companies still use their own mail servers for many different reasons. One of these reasons is to maintain the privacy that they want to keep in their own hands. Many configuration mistakes can be made by administrators, which in the worst cases will allow us to read all the emails sent and received, which may even contain confidential or sensitive information. Some of these configuration options include:
Setting
Description
auth_debug
Enables all authentication debug logging.
auth_debug_passwords
This setting adjusts log verbosity, the submitted passwords, and the scheme gets logged.
auth_verbose
Logs unsuccessful authentication attempts and their reasons.
auth_verbose_passwords
Passwords used for authentication are logged and can also be truncated.
auth_anonymous_username
This specifies the username to be used when logging in with the ANONYMOUS SASL mechanism.
Footprinting the Service
By default, ports 110 and 995 are used for POP3, and ports 143 and 993 are used for IMAP. The higher ports (993 and 995) use TLS/SSL to encrypt the communication between the client and server. Using Nmap, we can scan the server for these ports. The scan will return the corresponding information (as seen below) if the server uses an embedded certificate.
Nmap
IMAP / POP3
For example, from the output, we can see that the common name is mail1.inlanefreight.htb, and the email server belongs to the organization Inlanefreight, which is located in California. The displayed capabilities show us the commands available on the server and for the service on the corresponding port.
If we successfully figure out the access credentials for one of the employees, an attacker could log in to the mail server and read or even send the individual messages.
cURL
IMAP / POP3
If we also use the verbose (-v) option, we will see how the connection is made. From this, we can see the version of TLS used for encryption, further details of the SSL certificate, and even the banner, which will often contain the version of the mail server.
IMAP / POP3
To interact with the IMAP or POP3 server over SSL, we can use openssl, as well as ncat. The commands for this would look like this:
OpenSSL - TLS Encrypted Interaction POP3
IMAP / POP3
OpenSSL - TLS Encrypted Interaction IMAP
IMAP / POP3
Once we have successfully initiated a connection and logged in to the target mail server, we can use the above commands to work with and navigate the server. We want to point out that the configuration of our own mail server, the research for it, and the experiments we can do together with other community members will give us the know-how to understand the communication taking place and what configuration options are responsible for this.
In the SMTP section, we have found the user robin. Another member of our team was able to find out that the user also uses his username as a password (robin:robin). We can use these credentials and try them to interact with the IMAP/POP3 services.
---------------------------------------------------------------------------------------------------------------------
pop3s commands
openssl s_client -connect 10.129.216.201:pop3s
USER robin\r\n
PASS robin\r\n
imaps commands
openssl s_client -connect 10.129.216.201:imaps
1 LOGIN robin robin
->Enumerating all emails
1 LIST ""*
1 SELECT DEV.DEPARTMENT.INT
1 fetch 1 all
Read particular fields in an email body
1 fetch 1 body[<field name>]
field names:
ALL: Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
FAST: Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
FULL: Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
BODY: Non-extensible form of BODYSTRUCTURE.
BODY[<section>]<<partial>>: The text of a particular body section. The section specification is a set of zero or more part specifiers delimited by periods. A part specifier is either a part number or one of the following: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT. An empty section specification refers to the entire message, including the header. You may even select only parts of a multipart MIME message and even specific octets within that part, see RFC 3501#section-6.4.5 for more details.
BODY.PEEK[<section>]<<partial>>: An alternate form of BODY[<section>] that does not implicitly set the \Seen flag.
BODYSTRUCTURE: The MIME body structure of the message. This is computed by the server by parsing the MIME header fields in the header and body MIME headers.
ENVELOPE: The envelope structure of the message. This is computed by the server by parsing the message header into the component parts, defaulting various fields as necessary.
FLAGS: The flags that are set for this message.
INTERNALDATE: The internal date of the message.
RFC822: Functionally equivalent to BODY[], differing in the syntax of the resulting untagged FETCH data in that the full RFC822 message is returned.
RFC822.HEADER: Functionally equivalent to BODY.PEEK[HEADER], with RFC822 header syntax returned.
RFC822.SIZE: The size of the message.
RFC822.TEXT: Functionally equivalent to BODY[TEXT], differing in the syntax of the resulting untagged FETCH data as RFC822.TEXT is returned.
UID: The unique identifier for the message.
So, 1 fetch 1 body[text] would read the content of the email
Last updated
Was this helpful?
