Difference between revisions of "Testing for IMAP/SMTP Injection (OTG-INPVAL-011)"

Revision as of 01:56, 6 November 2006

OWASP Testing Guide v2 Table of Contents

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
• To understand the scope of operation
• IMAP/SMTP command injection

Identifying vulnerable parameters

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://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1

The following examples can be used with this aim.

• Left the parameter with a null value:
  

http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1

• Substitute the value with a random value:
  

http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1

• Add other values to the parameter:
  

http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1

• Add other non usual characters (i.e.: \, ', ", @, #, !, |):
  

http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1

• To eliminate the parameter:
  

http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1

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://<webmail>/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://<webmail>/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

The scene S2 is a particular case of the IMAP/SMTP Injection technique. In this case, the attacker will have to realize an command injection blindly (Blind IMAP/SMTP Injection).

On the other hand, the last scene (S3) does not have relevancy in this paragraph.

Result Expected:

• List of vulnerable parameters
• Affected functionality
• Type of possible injection (IMAP/SMTP)

To understand the scope of operation

After having identified a vulnerable parameter (for example, "passed_id"), the affected functionality (for example, reading of emails) and the type of possible injection (for example, IMAP Injection), the next step before the commands injection consists of understanding the context in which the vulnerable parameter is executed.

If the application returns error messages, to identify the attacked command can turn out an easy task.

Let's suppose that as result of the previous phase, we have detected the vulnerable parameter "passed_id" used in the following request:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1

and using the following abuse case (to use an alphabetical value when a numerical value is waited):

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1

generates the following error message:

ERROR : Bad or malformed request.
Query: FETCH test:test BODY[HEADER]
Server responded: Error in IMAP command received by server.

In the previous example, the own error message has returned the name of the executed command and the associate parameters.

In other occasions, the error message ("not controlled" by the application) only it contains the name of the executed command, but a reading to the suitable RFC (see "Reference" paragraph) allows to deduce the rest of information that we expect to obtain as result of this phase.

If the application does not return sufficiently descriptive error messages, the attacker will have to analyze the affected functionality to deduce the possible commands (and parameters) associated with the above mentioned functionality. For example, if the detection of the vulnerable parameter has been realized trying to create a mailbox, it turns out logical to think that the IMAP command affected will be "CREATE" and, according to the RFC, it contains a only parameter which value corresponds to the mailbox name that is expected to create.

Result Expected:

• List of IMAP/SMTP commands affected
• Type, value and number of parameters waited by the affected IMAP/SMTP commands

IMAP/SMTP command injection

When the attacker has identified a vulnerable parameter and has analyzed the context in which it is executed, he is in disposition to materialize his attack.

In this point, we can meet two scenes:
1. The injection is possible in an not authenticated state: the affected functionality does not need that the user has been authenticated before, that is to say, is in a public zone of the application. In this case, the possible injected (IMAP) commands are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN and LOGOUT. 2. The injection is possible in an authenticated state: the exploitation of this vulnerability needs that the user has authentication credentials to accede to the affected functionality.

In any case, the typical structure of an IMAP/SMTP Injection is the following one:

• Header: ending of the expected command;
• Body: injection of the new command;
• Footer: beginning of the expected command.

Result Expected:

• Arbitrary IMAP/SMTP command injection

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents OWASP Testing Guide v2 Table of Contents

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.