3

I have a web server that let's me send an email (using PHP), and I can make the sender as anyone... why is this possible? And how is this not a security concern?

using the php mail function.

// To send HTML mail, the Content-type header must be set
$headers  = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";

// Additional headers
$headers .= 'To: Jon Ives <jives@apple.com>' . "\r\n";
$headers .= 'From: Tim Cook <tcook@apple.com>' . "\r\n";

$message = 'I need you to create a clear iPhone.';

// Mail it
mail($to, $subject, $message, $headers);

In the example above, I can pretend to send an email as Tim cook to anyone, I thought when you send an email... the senders address was reliable... why is it so easy to spoof the sender.

EDIT

Is their code I can use to prevent myself from receiving spoofed emails?

Also is there a way to spoof the date and time from an email? or is that generated by the receiving server?

For example if I added 

$headers .= 'Date: 2010-1-2 12:32:13' . "\r\n";
Arian Faurtosh
  • 17,987
  • 21
  • 77
  • 115
  • 12
    Welcome to how email works – John Conde Sep 23 '13 at 21:24
  • I've used this knowledge to send email from God@Heaven.Above before ;) – Izkata Sep 23 '13 at 21:26
  • 4
    The notion that the sender's address is reliable is called a "naive misconception". This is why we have things like [SPF](http://en.wikipedia.org/wiki/Sender_Policy_Framework) and [DKIM](http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail), and they still only prove that someone permitted to use one of those servers sent the mail, not necessarily that it was who the sending address purports to be. – Sammitch Sep 23 '13 at 21:28
  • @JohnConde Can you spoof the email time and date with headers? – Arian Faurtosh Sep 23 '13 at 21:29
  • Many common email clients will detect a discrepancy in the forged ones, and send them to spam/junk folders. – STLMikey Sep 23 '13 at 21:29
  • SPAM filters frown on this and often grab the offending message. – keithhatfield Sep 23 '13 at 21:29
  • Mail clients will warn the user that your mail is a spoof,most of them will block it as a spam. – mpm Sep 23 '13 at 21:29
  • Note that while you can completely forget the `From:` address, you can **NOT** forge the network path that a legitimate email from that forged address will take. The recipient can view the mail headers and see what it came from YOUR server, not the fake address' server. – Marc B Sep 23 '13 at 21:36
  • 4
    You can do the same thing with postal mail by just writing a different name and address on it. \*shrugs\* – Boann Sep 23 '13 at 22:13

2 Answers2

4

What you are talking about are forged messages; it is possible to send, although it is highly unlikely that the recipient will receive the message. There are security measures in place that will guard against message forgery:

  1. DomainKeys
  2. DKIM
  3. SPF
  4. SenderID

DomainKeys has been deprecated in favor of DKIM. The two are very similar. The SO post "Differences between DomainKeys vs DKIM?" describes the difference.

SPF and SenderID are sometimes confused with each other, but they are different; see SPF: SPF vs SenderID.

It comes down to the recipient's SMTP server to implement and utilize these technologies. For example, if mail is received but a SPF check fails, the message will be marked as spam, and then will go the "junk folder" but the message is still accepted. Taking it one step further, a SMTP server could also validate the DKIM signature of the message; if the validation fails, the message will not be accepted. These policies and mail paths are determined by the receiving mail server/client and vary greatly.

Sender Policy Framework (SPF) / SenderID

Sender Policy Framework (SPF) is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the Domain Name System (DNS). Mail exchangers use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators.

Source: Wikipedia

On the contrary to SPF, SenderID instead verifies the Purported Responsible Address (PRA), see RFC 4407.

In basic terms, this is a DNS check asking, "Can IP address X send mail for domain Y?"

Imagine this scenario: Susie writes a letter to Victoria. Preemptively, Susie tells Victoria that only Susie's brother John and Susie herself will deliver letters to her. So Susie gives the letter to John and tells him to walk it down the street and deliver it to Victoria. Victoria hears a knock on the door, and there is John with a letter from Susie; because of the agreement prior, Susie accepts the letter. Now a few days later, Susie writes another letter to Victoria, but John is sick and cannot deliver letters; so instead, Susie asks her neighbor Rick to walk the letter down the street and deliver it to Victoria. Rick knocks on Victoria's door and says he has a letter from Susie. Victoria declines the letter and does not accept it (or maybe she puts it on table to verify it later in case it has a chance of being legitimate), because she expects only Susie and John to be delivering letters from Susie.

Example SPF Record for example.com:

spf2.0/mfrom ptr:mx.example.com +a +ip4:192.168.1.1 -all

This SPF record says that only mail from the server mx.example.com, all A records belonging to example.com and the IPv4 address 192.168.1.1 can send email for example.com, none others (-all).

DomainKeys Identified Mail (DKIM) / DomainKeys

I'll focus on DKIM since DomainKeys is half-deprecated, but the premise is the same.

DomainKeys Identified Mail (DKIM) is a method for associating a domain name with an email message, thereby allowing a person, role, or organization to claim some responsibility for the message. The association is set up by means of a digital signature which can be validated by recipients. Responsibility is claimed by a signer —independently of the message's actual authors or recipients— by adding a DKIM-Signature: field to the message's header. The verifier recovers the signer's public key using the DNS, and then verifies that the signature matches the actual message's content.

DKIM is different than SPF in that SPF is tied solely to DNS, while DKIM is a signature that exists within the mail itself. If you are familiar with the concept of public-key cryptography, that is what DKIM essentially is. The sender has a private key used to encrypt messages; it makes the public key accessible (via a DNS TXT record) for only decrypting.

In basic terms DKIM asks the question, "Is the message I'm receiving really from sender X?"

Imagine this scenario: Susie writes a letter to Victoria. Along with the letter, there is an encrypted code that Susie devised. Susie asks Rick to walk the letter over to Victoria. Rick knocks on Victoria's door and presents the letter with the encrypted code. Before accepting the letter, Victoria takes out her "decryption book" (think of it like the WhitePages - a publicly accessible list of decryption codes, but not for encryption); she decrypts the code to find that it is in fact Susie's signature, and then accepts the message from Rick. Remember, nobody can forge Susie's signature unless Susie releases her encryption key.

Is there a way to spoof the date and time from an email?

Kind of. The sending date is as you have it:

$headers .= 'Date: 2010-1-2 12:32:13' . "\r\n";

However, the receiving SMTP server will always put its own timestamp on the message. Depending on the mail service/client, the Date header may be read, or another meta timestamp may be read (e.g. that the receiving SMTP server added to the header).

As an example, I believe gmail will honor the Date header the sender puts in place - I've seen emails from Jan 1, 1970 (the beginning of the Unix epoch). This could be a bad idea, especially with mailboxes that have a lot in their inbox - the message could get lost somewhere in the middle, or at the very end.

Community
  • 1
  • 1
zamnuts
  • 9,492
  • 3
  • 39
  • 46
0

The remote server is resolved as apple.com, so it will always go there.

Now all the remote server knows is your SMTP address (not that it cares)

And since the sender is mentioned in the email header, that one is being used.

Conclusion: It's just how email works.

I hope i explained as easy as possible.

MichaelvdNet
  • 1,074
  • 2
  • 14
  • 22