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).

The parameters on which it is necessary to give special attention are 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. Let's suppose that one wants to analyze the parameter "mailbox" of the following request: http:// /src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1 The following examples can be used with this aim. http:// /src/read_body.php?mailbox=&passed_id=46106&startMessage=1 http:// /src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1 http:// /src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1 http:// /src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1 http:// /src/read_body.php?passed_id=46106&startMessage=1
 * Left the parameter with a null value:
 * Substitute the value with a random value:
 * Add other values to the parameter:
 * Add other non usual characters (i.e.: \, ', ", @, #, !, |):
 * To eliminate the parameter:

As result of a abuse case, we can meet three situations: S1 - The application returns a error code/message S2 - The application does not return a error code/message, but it does not realize the requested operation S3 - The application does not return a error code/message and realizes the operation requested with normality

The scenes S1 and S2 represent situations in which the IMAP/SMTP Injection technique can haver had success.

From the point of view of an attacker the S1 is the wished situation because the own error message allows him to detect easily the vulnerable parameter, and to know closely the context in which the above mentioned parameter is executed.

For example, let's suppose that the query on the email headers generates the next request: http:// /src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0

An attacker might modify the value of the parameter INBOX injecting the character " (%22 using URL encoding): http:// /src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0

Obtaining the following response of the application: ERROR: Bad or malformed request. Query: SELECT "INBOX"" Server responded: Unexpected extra arguments to Select

... Result Expected: To understand the scope of operation
 * List of vulnerable parameters
 * Affected functionality
 * Type of possible injection (IMAP/SMTP)

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

... Result Expected: ...

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