Archives

Here are all the past articles.

OWASP

I: Abuse of Functionality
II: Exploitation of Authentication
III: Injection
IV: Injection Part II

Data Forensics

Photorec
Windows

Kali

Nikto
John the Ripper
Shred
Burp Suite Set Up Tutorial Small Intruder
I: Wireshark

Web App Vulns

Subdomains
Baker's Dozen

Etcetera

One Time Pad
PHP Backdoor File Analysis
Hiring Procedures
SPF and Email Spoofing

SPF and Email Spoofing

The simple block of code that is used by PHP devs everywhere for "Contact Us" forms everywhere:

        <?php
        $to = "[email protected]";
        $subject = "Hi";
        $txt = $_POST["body"];
        $headers = "From: $_POST["contact"]";
        mail($to,$subject,$txt,$headers);
        ?>

So the idea came, "What if I just put whatever I want?"

        <?php
        $to = "[email protected]";
        $subject = "Password Change";
        $txt = "Change your password by visiting here - [VIRUS LINK HERE]!";
        $headers = "From: [email protected]";
        mail($to,$subject,$txt,$headers);
        ?>


What is stopping a person from just filling any header data to masquerade as a legitimate contact?
The solution to this little issue is Sender Policy Framework (SPF.)

When the receiving mail server gets an email it will look at the 'Return-Path' header and grab the domain from the sender's address. It will then check the SPF record, which is stored on DNS servers, that correlates with the 'Return-Path's domain and ensure that the senders IP/domain (Received header) is approved of by the SPF.

Simple example:
v=spf1 include:_spf.google.com ~all

The beginning:
"v=spf1" is the version definition. spf1 is the only version, it is mandatory and will be at the beginning of all SPF records.

The middle:
The testing parameters are here. How the sender's domain is compared to DNS entry can be specified in many ways (There is a ton of different nomenclature; explanation listed here: http://www.zytrax.com/books/dns/ch9/spf.html) For this example there is only an 'include' which tells the user to restart the SPF verification test against this new domain (_spf.google.com instead of google.com)

So if you drop that domain into an SPF reader you get this:
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

Same deal, just three includes, check the first netblocks and you get this:
v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

So if an email's sender's domain matches with any of the IP addresses listed in the SPF record then it will pass.

The ending:
+all = pass
?all = neutral = email will be accepted
~all = soft fail = will be accepted, but marked
-all = fail = will be rejected


This is where the SPF record gives instruction on what to do with an email that failed to meet the parameters fails. So this is the part that we are interested in when it comes to spoofing.

Complex example:
v=spf1 mx include:_spf.google.com +a:mail1.keybase.io +a:mail2.keybase.io -all
google-site-verification=2_x9kakVn08nlY19drRYak0gT8V7--0gD30LuHeQgDc

In this example you can see that keybase.io is using a hard fail for any message that fails to meet its parameters. So what happens to the message?


A one way ticket to the gmail's automatic spam filter.


Here are a couple of tools to check a site's SPF:
http://www.kitterman.com/spf/validate.html
http://mxtoolbox.com/spf.aspx