• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Mail Command Injection

Page history last edited by Robert Auger 14 years, 3 months ago

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.