Project: WASC Threat Classification
Threat Type: Attack
Reference ID: WASC-30
Mail Command Injection
Mail Command Injection is an attack technique used to exploit mail servers and webmail applications that construct IMAP/SMTP statements from user-supplied input that is not properly sanitized. Depending on the type of statement taken advantage by the attacker, we meet two types of injections: IMAP and SMTP Injection. An IMAP/SMTP Injection may make it possible to access a mail server which you previously had no access to before-hand. In some cases, these internal systems do not have the same level of infrastructure security hardening applied to them as most front-end web servers. Hence, attackers may find that the mail server yields better results in terms of exploitation. On the other hand, this technique allows to evade possible restrictions that could exist at application level (CAPTCHA, maximum number of requests, etc.).
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(s);
Footer: beginning of the expected command.
It is important to note that in order to execute the IMAP/SMTP command, the previous command must have been terminated with the CRLF (%0d%0a) sequence.
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
Example Attack Scenarios
IMAP Injection
Since command injection is done over the IMAP server, the format and specifications of this protocol must be followed. Webmail applications typically communicate with the IMAP server to carry out their operations in most cases and hence are more vulnerable to this kind of attack.
IMAP Injection is also possible in an unauthenticated state. In this scenario, IMAP commands are available but limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN and LOGOUT.
Let's look at an example of IMAP Injection by exploiting the functionalities of reading a message. Assume that the webmail application uses the parameter "message_id" to store the identifier of the message that the user wants to read. When a request containing the message identifier is sent the request would appear as:
http://<webmail>/read_email.php?message_id=<number>
Suppose that the webpage "read_email.php", responsible for showing the associated message, transmits the request to the IMAP server without performing any validation over the value <number> given by the user. The command sent to the mail server would look like this:
FETCH <number> BODY[HEADER]
In this context, a malicious user could try to conduct IMAP Injection attacks through the parameter "message_id" used by the application to communicate with the mail server. For example, the IMAP command "CAPABILITY" could be injected using the next sequence:
http://<webmail>/read_email.php?message_id=1 BODY[HEADER]%0d%0aV001 CAPABILITY%0d%0aV002 FETCH 1
This would produce the next sequence on IMAP commands in the server:
???? FETCH 1 BODY[HEADER]
V001 CAPABILITY
V002 FETCH 1 BODY[HEADER]
where:
Header = 1 BODY[HEADER]
Body = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 1
SMTP Injection
Since command injection is performed over the SMTP server, the format and specifications of this protocol must adhere to this protocol. Due to the limited operations permitted by the application using the SMTP protocol, we are basically limited to sending e-mail. The use of SMTP Injection requires that the user be authenticated previously, so it is necessary that the attacker have a valid webmail account.
Let's look at an example for evading the limit of maximum emails that are allowed to be sent.
Suppose a webmail application restricts the number of emails sent in a chosen time period. SMTP Injection would allow evasion of this restriction simply by adding as many RCPT commands as destinations that the attacker wants:
POST http://<webmail>/compose.php HTTP/1.1
-----------------------------134475172700422922879687252
Content-Disposition: form-data; name="subject"
Test
.
MAIL FROM: external@domain1.com
RCPT TO: external@domain1.com
RCPT TO: external@domain2.com
RCPT TO: external@domain3.com
RCPT TO: external@domain4.com
Data
This is an example of SMTP Injection attack
.
-----------------------------134475172700422922879687252
...
This would produce the following sequence of SMTP commands to be sent to the mail server:
MAIL FROM: <mailfrom>
RCPT TO: <rcptto>
DATA
Subject: Test
.
MAIL FROM: external@domain.com
RCPT TO: external@domain1.com
RCPT TO: external@domain2.com
RCPT TO: external@domain3.com
RCPT TO: external@domain4.com
DATA
This is an example of SMTP Injection attack
.
...
References
"RFC 0821: Simple Mail Transfer Protocol"
[1] http://www.ietf.org/rfc/rfc0821.txt
"RFC 3501: Internet Message Access Protocol - Version 4rev1"
[2] http://www.ietf.org/rfc/rfc3501.txt
"CRLF Injection by Ulf Harnhammar"
[3] http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-05/0077.html
"Email Injection - Injecting email headers"
[4] http://www.securephpwiki.com/index.php/Email_Injection
"PHP Mail Functions discussions"
[5] http://www.php.net/manual/en/ref.mail.php#62027
"E-mail Spoofing and CDONTS.NEWMAIL", David Litchfield
[6] http://www.nextgenss.com/papers/aspmail.pdf
"Testing for IMAP/SMTP Injection", Vicente Aguilera.
[7] http://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection
"MX Injection : Capturing and Exploiting Hidden Mail Servers", Vicente Aguilera.
[8] http://www.webappsec.org/projects/articles/121106.pdf
Comments (0)
You don't have permission to comment on this page.