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

Latest revision as of 12:04, 8 August 2014

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

1 Summary
2 How to Test
3 References

Summary

This threat affects all applications that 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, due to input data not being properly sanitized.

The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing.

An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the front-end web servers. Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1).

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

Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2 is the tester bypassing the webmail client and interacting with the back-end mail servers directly.

This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested.

Some examples of attacks using the IMAP/SMTP Injection technique are:

Exploitation of vulnerabilities in the IMAP/SMTP protocol
Application restrictions evasion
Anti-automation process evasion
Information leaks
Relay/SPAM

How to Test

The standard attack patterns are:

Identifying vulnerable parameters
Understanding the data flow and deployment structure of the client
IMAP/SMTP command injection

Identifying vulnerable parameters

In order to detect vulnerable parameters, the tester has to analyze the application's ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the back-end application that will answer with a "HTTP 200 OK" response message.

It is important to note that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested.

IMAP special parameters that should be used are:

On the IMAP server	On the SMTP server
Authentication	Emissor e-mail
operations with mail boxes (list, read, create, delete, rename)	Destination e-mail
operations with messages (read, copy, move, delete)	Subject
Disconnection	Message body
	Attached files

In this example, the "mailbox" parameter is being tested by manipulating all requests with the parameter in:

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

The following examples can be used.

Assign a null value to the parameter:

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 non standard special characters (i.e.: \, ', ", @, #, !, |):

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

Eliminate the parameter:

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

The final result of the above testing gives the tester three possible situations:
S1 - The application returns a error code/message
S2 - The application does not return an error code/message, but it does not realize the requested operation
S3 - The application does not return an error code/message and realizes the operation requested normally

Situations S1 and S2 represent successful IMAP/SMTP injection.

An attacker's aim is receiving the S1 response, as it is an indicator that the application is vulnerable to injection and further manipulation.

Let's suppose that a user retrieves the email headers using the following HTTP 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 by injecting the character " (%22 using URL encoding):

http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0

In this case, the application answer may be:

ERROR: Bad or malformed request.
Query: SELECT "INBOX""
Server responded: Unexpected extra arguments to Select

The situation S2 is harder to test successfully. The tester needs to use blind command injection in order to determine if the server is vulnerable.

On the other hand, the last situation (S3) is not revelant in this paragraph.

Result Expected:

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

Understanding the data flow and deployment structure of the client

After identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then design a testing plan to further exploit the application.

In this test case, we have detected that the application's "passed_id" parameter is vulnerable and is used in the following request:

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

Using the following test case (providing an alphabetical value when a numerical value is required):

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

will generate 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 this example, the error message returned the name of the executed command and the corresponding parameters.

In other situations, the error message ("not controlled" by the application) contains the name of the executed command, but reading the suitable RFC (see "Reference" paragraph) allows the tester to understand what other possible commands can be executed.

If the application does not return descriptive error messages, the tester needs to analyze the affected functionality to deduce all the possible commands (and parameters) associated with the above mentioned functionality. For example, if a vulnerable parameter has been detected in the create mailbox functionality, it is logical to assume that the affected IMAP command is "CREATE". According to the RFC, the CREATE command accepts one parameter which specifies the name of the mailbox to create.

Result Expected:

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

IMAP/SMTP command injection

Once the tester has identified vulnerable parameters and has analyzed the context in which they are executed, the next stage is exploiting the functionality.

This stage has two possible outcomes:
1. The injection is possible in an unauthenticated state: the affected functionality does not require the user to be authenticated. The injected (IMAP) commands available are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN, and LOGOUT.
2. The injection is only possible in an authenticated state: the successful exploitation requires the user to be fully authenticated before testing can continue.

In any case, the typical structure of an IMAP/SMTP Injection is as follows:

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

It is important to remember that, in order to execute an IMAP/SMTP command, the previous command must be terminated with the CRLF (%0d%0a) sequence.

Let's suppose that in the stage 1 ("Identifying vulnerable parameters"), the attacker detects that the parameter "message_id" in the following request is vulnerable:

http://<webmail>/read_email.php?message_id=4791

Let's suppose also that the outcome of the analysis performed in the stage 2 ("Understanding the data flow and deployment structure of the client") has identified the command and arguments associated with this parameter as:

FETCH 4791 BODY[HEADER]

In this scenario, the IMAP injection structure would be:

http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791

Which would generate the following commands:

???? FETCH 4791 BODY[HEADER]
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]

where:

Header = 4791 BODY[HEADER]
Body   = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791

Result Expected:

Arbitrary IMAP/SMTP command injection

References

Whitepapers

RFC 0821 “Simple Mail Transfer Protocol”.
RFC 3501 “Internet Message Access Protocol - Version 4rev1”.
Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers" - http://www.webappsec.org/projects/articles/121106.pdf

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

Latest revision as of 12:04, 8 August 2014

Summary

How to Test

Identifying vulnerable parameters

Understanding the data flow and deployment structure of the client

IMAP/SMTP command injection

References

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Reference

Tools

@@ Line 1: / Line 1: @@
-{{Template:OWASP Testing Guide v2}}
+{{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== 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.
+This threat affects all applications that 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, due to input data not being properly sanitized.
-<br>
+The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to conduct direct testing.
+An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the front-end web servers. Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1).
-==Description of the Issue==
+<center>[[Image:imap-smtp-injection.png]]<br>
-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.
+Figure 1 - Communication with the mail servers using the IMAP/SMTP Injection technique.</center><br>
-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).
-<center>[[Image:imap-smtp-injection.png]]
+Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2 is the tester bypassing the webmail client and interacting with the back-end mail servers directly.
-Figure 1 - Communication with the mail servers using the IMAP/SMTP Injection technique.</center>
-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.
+This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested.
-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:
+Some examples of attacks using the IMAP/SMTP Injection technique are:
 * Exploitation of vulnerabilities in the IMAP/SMTP protocol
 * Application restrictions evasion
@@ Line 25: / Line 27: @@
 * Relay/SPAM
-== Black Box testing and example ==
-Usually the main steps of the attack pattern are the following:
+== How to Test ==
+The standard attack patterns are:
 * Identifying vulnerable parameters
-* To understand the scope of operation
+* Understanding the data flow and deployment structure of the client
 * IMAP/SMTP command injection
-<br>
-'''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:
+===Identifying vulnerable parameters===
+In order to detect vulnerable parameters, the tester has to analyze the application's ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the back-end application that will answer with a "HTTP 200 OK" response message.
+It is important to note that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested.
+IMAP special parameters that should be used are:
 {| border=1
   || '''On the IMAP server''' || '''On the SMTP server'''
@@ Line 55: / Line 60: @@
 |}
-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:
+In this example, the "mailbox" parameter is being tested by manipulating all requests with the parameter in:
 <pre>
 http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1
 </pre>
-The following examples can be used with this aim.
-* Left the parameter with a null value:<br>
+The following examples can be used.
+* Assign a null value to the parameter:<br>
 <pre>
 http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1
@@ Line 74: / Line 80: @@
 http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1
 </pre>
-* Add other non usual characters (i.e.: \, ', ", @, #, !, |):<br>
+* Add non standard special characters (i.e.: \, ', ", @, #, !, |):<br>
 <pre>
 http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1
 </pre>
-* To eliminate the parameter:<br>
+* Eliminate the parameter:<br>
 <pre>
 http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1
 </pre>
-As result of a abuse case, we can meet three situations: <br>
+The final result of the above testing gives the tester three possible situations: <br>
 S1 - The application returns a error code/message <br>
-S2 - The application does not return a error code/message, but it does not realize the requested operation <br>
+S2 - The application does not return an error code/message, but it does not realize the requested operation <br>
-S3 - The application does not return a error code/message and realizes the operation requested with normality <br>
+S3 - The application does not return an error code/message and realizes the operation requested normally <br>
-The scenes S1 and S2 represent situations in which the IMAP/SMTP Injection technique can haver had success.
+Situations S1 and S2 represent successful IMAP/SMTP injection.
-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.
+An attacker's aim is receiving the S1 response, as it is an indicator that the application is vulnerable to injection and further manipulation.
-For example, let's suppose that the query on the email headers generates the next request:
+Let's suppose that a user retrieves the email headers using the following HTTP request:
 <pre>
 http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0
 </pre>
-An attacker might modify the value of the parameter INBOX injecting the character " (%22 using URL encoding):
+An attacker might modify the value of the parameter INBOX by injecting the character " (%22 using URL encoding):
 <pre>
 http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0
 </pre>
-Obtaining the following response of the application:
+In this case, the application answer may be:
 <pre>
 ERROR: Bad or malformed request.
@@ Line 109: / Line 119: @@
 </pre>
-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.
+The situation S2 is harder to test successfully. The tester needs to use blind command injection in order to determine if the server is vulnerable.
+On the other hand, the last situation (S3) is not revelant in this paragraph.
 <br><br>
 '''Result Expected:'''<br>
@@ Line 118: / Line 130: @@
 * Type of possible injection (IMAP/SMTP)
 <br>
-'''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.
+===Understanding the data flow and deployment structure of the client===
+After identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then design a testing plan to further exploit the application.
-Let's suppose that as result of the previous phase, we have detected the vulnerable parameter "passed_id" used in the following request:
+In this test case, we have detected that the application's "passed_id" parameter is vulnerable and is used in the following request:
 <pre>
 http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1
 </pre>
-and using the following abuse case (to use an alphabetical value when a numerical value is waited):
+Using the following test case (providing an alphabetical value when a numerical value is required):
 <pre>
 http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1
 </pre>
-generates the following error message:
+will generate the following error message:
 <pre>
 ERROR : Bad or malformed request.
@@ Line 141: / Line 154: @@
 </pre>
-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.
+In this example, the error message returned the name of the executed command and the corresponding parameters.
+In other situations, the error message ("not controlled" by the application) contains the name of the executed command, but reading the suitable RFC (see "Reference" paragraph) allows the tester to understand what other possible commands can be executed.
-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.
+If the application does not return descriptive error messages, the tester needs to analyze the affected functionality to deduce all the possible commands (and parameters) associated with the above mentioned functionality. For example, if a vulnerable parameter has been detected in the create  mailbox functionality, it is logical to assume that the affected IMAP command is "CREATE". According to the RFC, the CREATE command accepts one parameter which specifies the name of the mailbox to create.
 <br><br>
 '''Result Expected:'''<br>
 * List of IMAP/SMTP commands affected
-* Type, value and number of parameters waited by the affected IMAP/SMTP commands
+* Type, value, and number of parameters expected by the affected IMAP/SMTP commands
 <br>
-'''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:<br>
+===IMAP/SMTP command injection===
-. 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.<br>
-. 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:
+Once the tester has identified vulnerable parameters and has analyzed the context in which they are executed, the next stage is exploiting the functionality.
+This stage has two possible outcomes:<br>
+. The injection is possible in an unauthenticated state: the affected functionality does not require the user to be authenticated. The injected (IMAP) commands available are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN, and LOGOUT.<br>
+. The injection is only possible in an authenticated state: the successful exploitation requires the user to be fully authenticated before testing can continue.
+In any case, the typical structure of an IMAP/SMTP Injection is as follows:
 * Header: ending of the expected command;
 * Body: injection of the new command;
 * Footer: beginning of the expected command.
-<br><br>
+It is important to remember that, in order to execute an IMAP/SMTP command, the previous command must be terminated with the CRLF (%0d%0a) sequence.
+Let's suppose that in the stage 1 ("Identifying vulnerable parameters"), the attacker detects that the parameter "message_id" in the following request is vulnerable:
+<pre>
+http://<webmail>/read_email.php?message_id=4791
+</pre>
+Let's suppose also that the outcome of the analysis performed in the stage 2 ("Understanding the data flow and deployment structure of the client") has identified the command and arguments associated with this parameter as:
+<pre>
+FETCH 4791 BODY[HEADER]
+</pre>
+In this scenario, the IMAP injection structure would be:
+<pre>
+http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791
+</pre>
+Which would generate the following commands:
+<pre>
+???? FETCH 4791 BODY[HEADER]
+V100 CAPABILITY
+V101 FETCH 4791 BODY[HEADER]
+</pre>
+where:
+<pre>
+Header = 4791 BODY[HEADER]
+Body   = %0d%0aV100 CAPABILITY%0d%0a
+Footer = V101 FETCH 4791
+</pre>
+<br>
 '''Result Expected:'''<br>
 * Arbitrary IMAP/SMTP command injection
 <br>
-== Gray Box testing and example ==
-'''Testing for Topic X vulnerabilities:'''<br>
-...<br>
-'''Result Expected:'''<br>
-...<br><br>
 == References ==
 '''Whitepapers'''<br>
-...<br>
+* RFC 0821 “Simple Mail Transfer Protocol”.
-'''Tools'''<br>
+* RFC 3501 “Internet Message Access Protocol - Version 4rev1”.
-...<br>
+* Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers" - <u>http://www.webappsec.org/projects/articles/121106.pdf</u>
-{{Category:OWASP Testing Project AoC}}
-[[OWASP Testing Guide v2 Table of Contents]]
-{{Template:Stub}}