Most of individuals use the Internet for communication with one another via email message on in regular basis. For this reason, most web admins allows their customers to contact them —giving a suggestion, reporting a problem, or asking for a feedback, use a contact form that may send the feedback to the webmaster’s email. Unfortunately, a lot of the web developers don’t have sufficient information about securing code, and a few of them use a ready-made library or framework, which suffer from many well-known vulnerabilities. These are published already and have been patched by the seller and their exploits can be found on the web, however a lot of the developers are too lazy to upgrade to the newest version.
Today we’re going to speak about Email Injections that an attacker may use it to send out spam out of your mail server utilizing your mail form.
Email injection is a security vulnerability that may occur in Internet applications which can be used to send email messages. It is the e-mail equal of HTTP Header Injection. Like SQL injection attacks, this vulnerability is one in all a general class of vulnerabilities that occur when one programming language is embedded inside another.
When a form is added to a Web page that submits data to a Web application, a malicious user might exploit the MIME format to append additional information to the message being sent, such as a brand new list of recipients or a totally different message body. Because the MIME format uses a carriage return to delimit the information in a message, and only the raw message determines its eventual destination, adding carriage returns to submitted form data can allow a easy guestbook to be used to send hundreds of messages without delay. A malicious spammer may use this tactic to send large numbers of messages anonymously.
Email injection is a sort of injection attack that hits the PHP built-in mail function. It allows the malicious attacker to inject any of the mail header fields like, BCC , CC, Subject, etc., which allows the hacker to send out spam from their victims’ mail server through their victims’ contact form. For this reason, this attack is known as Email Injection, or mail form spamming. This vulnerability will not be limited to PHP. It can probably affect any application that sends email messages based on input from arbitrary users. The main reason of this attack is improper user input validation or that there is no such thing as a validation and filtration in any respect.
How Does Email Injection Work?
To explore how the e-mail injection works, we should always know exactly how the PHP email function works. Let’s take a look at PHP mail function description from PHP manual Mail() :
bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )
As you’ll be able to notice that it takes three mandatory parameters (“to, subject, and message”) and another optional parameters and the function returns a Boolean worth which is True or False.
So let’s take a look to a vulnerable code to exhibit this vulnerability:
<?php $to="[email protected]"; if (!isset($_POST["send"])) ?> <form method="POST" motion="<?=$_SERVER["PHP_SELF"];?>"> From: <input type="text" name="sender"> Subject : <input type="text" name="subject"> Message : <textarea name="message" rows="10" cols="60" lines="20"></textarea> <input type="submit" name="send" worth="Send"> </form> <? else // the shape has been submitted $from=$_POST["sender"]; // send mail if (mail($to,$_POST["subject"],$_POST["message"],"From: $fromn")) echo "Your mail has been sent successfully"; else ] echo "An error has been occurred !"; ?>
The previous code will likely be used for demonstration functions and for explanation we are going to divide the previous code into three parts:
The First Part
<?php $to="[email protected]"; if (!isset($_POST["send"])) ?>
This code will check if the shape is submitted or not. The response will likely be different if this code returns “True or False.” If it returns, “True,” it implies that the shape will not be submitted. The form will show up and be awaiting user inputs. On the opposite hand, if it returns “False,” it implies that the shape is submitted, so the e-mail will likely be sent.
The Second Part
<form method="POST" motion="<?=$_SERVER["PHP_SELF"];?>"> From: <input type="text" name="sender"> Subject : <input type="text" name="subject"> Message : <textarea name="message" rows="10" cols="60" lines="20"></textarea> <input type="submit" name="send" worth="Send"> </form>
The second part is an HTML form tag that may show up if the primary part returns “True,” which asks for user inputs.
The Third Part
<? else // the shape has been submitted $from=$_POST["sender"]; // send mail if (mail($to,$_POST["subject"],$_POST["message"],"From: $fromn")) echo "Your mail has been sent successfully"; else ] echo "An error has been occurred !"; ?>
as you’ll be able to see in the previous code specially this line
the Mail function takes its subject , message, and from from parameters and sends the mail.
If it’s successfully sent it, it can print “Your mail has been sent successfully,” and if that is an error, it can return “An error has been occurred.”
Where is the problem, then? The main problem for any injection attack “Not Only Email Injection,” is trusting user inputs or improper input validation. As you’ll be able to see in the third a part of code, the mail function takes its argument directly from the user with none input validation, where the Mail function takes subject, message, and from from parameters with out filtration and validation. So, the malicious attacker can control these values of subject , message and form parameters which the developer can use directly.
Email Injection Practical Example Demo
For demonstration functions, we are going to use the previous vulnerable code. Furthermore, we are going to submit the mail function parameters with the next values:
The row output data looks like the next:
From the attacker viewpoint, there are many additional fields that may be injected in the mail header. For more information see RFC 822. For example, we are able to inject a CC or BCC that permits the attacker to add more recipients to the message, however before adding a brand new argument we’ve got to add a brand new line feed that separates each field form another, the hexadecimal worth for the road feed is “0x0A.” Here are some examples:
Inject Cc and Bcc after sender argument
So now, the message will likely be sent to the recipient and recipient1 accounts.
Inject To argument
From:[email protected]:To:[email protected]
Now the message will likely be sent to the original recipient and the attacker account.
Inject Subject argument
From:[email protected]:Subject:This’s Fake Subject
The fake subject will likely be added to the original subject and in some cases will replace it. It will depend on the mail service behavior.
Change the body of the message
Inject a two-line feed, then write your message to change the body of the message.
From:[email protected]::My New Fake Message.
The fake message will likely be added to the original message.
How to Protect against Email Injection Attacks?
- Never trust user input fields. All user inputs needs to be considered untrusted and probably malicious. Applications that process untrusted input might become vulnerable to attacks such as Buffer Overflows, SQL Injection, OS Commanding, Denial of Service and Email Injection.
- Use regular expressions to filter user data. For example, we are able to search for (r or n) in the input string.
- Use external components and libraries that provide protection against this problem like ZEND mail, PEAR mail and swift mailer.
- ModSecurity can put a stop to email injection on the server level. With ModSecurity, it’s doable to scan the POST or GET body for BCC, CC, or To and reject any request that contains these letters.