This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

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

From OWASP
Jump to: navigation, search
(Black Box testing and example)
(Black Box testing and example)
Line 52: Line 52:
 
<center>
 
<center>
 
<table width="60%">
 
<table width="60%">
<tr><td align=center>'''On the IMAP server'''</td><td align=center>'''On the SMTP server'''</td></tr>
+
<tr><td>'''On the IMAP server'''</td><td>'''On the SMTP server'''</td></tr>
 
<tr><td>Authentication</td><td>Emissor e-mail</td></tr>
 
<tr><td>Authentication</td><td>Emissor e-mail</td></tr>
 
<tr><td>operations with mail boxes (list, read, create, delete, rename)</td><td>Destination e-mail</td></tr>
 
<tr><td>operations with mail boxes (list, read, create, delete, rename)</td><td>Destination e-mail</td></tr>

Revision as of 12:15, 4 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).

Imap-smtp-injection.png 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).

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

  • On the SMTP server, those used in the following operations:

- Emissor e-mail
- Destination e-mail
- Subject
- Message body
- Attached files

On the IMAP serverOn the SMTP server
AuthenticationEmissor e-mail
operations with mail boxes (list, read, create, delete, rename)Destination e-mail

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

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.