Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

Brief Summary
This threat affect all those applications that they communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers with that one communicates the web application, due to input data that they have not been sanitized correctly.

Description of the Issue
The IMAP/SMTP Injection technique is really useful if the mail servers, which the webmail application communicates, are not directly accessible from Internet. In other cases, this technique is nonsense and results more practise do a direct connection to those servers, without using the webmail applications.

This technique facilitate that, mail servers that could not be accessibles directly from Internet, and then be not so secured and updated, become visibles and accessibles publicly to Internet users/attackers (see the scheme presented in Figure 1).



Figure 1 - Communication with the mail servers using the IMAP/SMTP Injection technique.

In the Figure 1, the steps 1, 2 and 3 (green route) represent the usual way that follow a request from a client of the webmail application: from client point of view, the mail servers are not directly visible from Internet. The steps 1 and 2' (red route) compose the virtual way that the request, that a user that tries to exploit the IMAP/SMTP Injection technique, follows to operate with the mail servers evading the restrictions imposed by te webmail application: to the client, its vision is that the mail servers have their mail ports are opened to Internet and is capable to communicate directly to them.

The use of this technique permits a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server attacked.

Some examples of attacks using the IMAP/SMTP Injection technique:
 * Exploitation of vulnerabilities in the IMAP/SMTP protocol
 * Application restrictions evasion
 * Anti-automation process evasion
 * Information leaks
 * Relay/SPAM

Black Box testing and example
Usually the main steps of the attack pattern are the following: Identifying vulnerable parameters
 * Identifying vulnerable parameters
 * To understand the scope of operation
 * IMAP/SMTP command injection

To detect a vulnerable parameter implies analyzing all the input data to the application. This analysis will consist, as it happens in similar injections, in probing abuse cases (doing requests with no expected values by the application) and analyzing both the response and the behavior of the application.

In this case, the auditor/attacker possesses additional information: the input data susceptible of being vulnerable will be all those used in the communication with the mail servers. Depending on the protocol in which the vulnerable parameter is used, we will speak about IMAP Injection (attacks to the IMAP protocol) or SMTP Injection (attacks to the SMTP protocol).

Later there are enumerated the parameters on which it is necessary to give special attention. - authentication - operations with mail boxes (list, read, create, delete, rename) - operations with messages (read, copy, move, delete) - disconnection
 * On the IMAP server, those used in the following operations:

- Emissor e-mail - Destination e-mail - Subject - Message body - Attached files
 * On the SMTP server, those used in the following operations:

Since it has been mentioned previously, on each of the parameters related to these operations must be analyzed the abuse cases. The following examples can be used with this aim: - Left the parameter with a null value (i.e.: "mailbox=") - Substitute the value with a random value (i.e.: "mailbox="NotExists") - Add other values to the parameter (i.e.: "mailbox=INBOX PARAMETER2") - Add other non usual characters (i.e.: \, ', ", @, #, !, |) - To eliminate the parameter

... Result Expected: ... To understand the scope of operation

... Result Expected: ... IMAP/SMTP command injection

... Result Expected: ...

Gray Box testing and example
Testing for Topic X vulnerabilities: ... Result Expected: ...