My next class:

UPS Malware Spam Using Fake SPF Headers

Published: 2014-02-21. Last Updated: 2014-02-21 18:48:49 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

The "Sender Policy Framework" is a simple system to identify which mail servers are allowed to send e-mail on behalf of your domain. We have talked about this (and other standards like DMARC, DKIM) before.

These systems are usually implemented on your mail gateways. The outbound gateway will sign e-mail using your domain key (for DKIM). The receiving mail gateway will check if the headers are present and correct. The mail gateway will then add a special header with the result of the check, and this special header is then used by spam filters to decide if to keep the e-mail (or not).

It appears that spammers are learning and found a way to fool some badly configured mail gateways and spam filters. The spammer will add a header indicating that the e-mail passed the SPF validation. William sent us a sample of a UPS themed e-mail that included a malicious attachment.  It included the following headers:

Subject: UPS Delivery Notification Tracking Number : <random string>
Date: Mon, 17 Feb 2014 11:56:04 -0300
From: UPS Quantum View <auto-notify@ups.com>
X-Priority: 3
X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net)
Message-ID: <3b8bfaf8-830d-4804-94fa-96cf3eb3c052@ups.com>
Received-SPF: pass (google.com: domain of no-replay@ups.com does designate 192.123.32.83 as permitted sender) client-ip=192.123.32.83;
Received: from 192.123.32.83 (EHLO mailer.ups.com) (192.123.32.83)
Received: by mailer.ups.com (Postfix, from userid 1000) id A838D7824B;
X-Mailer: MIME-tools 5.41 (Entity 5.404)
X-Message-Status: s1:0
X-SID-PRA: UPS Quantum View<auto@ups.com>
X-SID-Result: TempError
Conversion-With-Loss: Yes

The red line indicates that the e-mail passed SPF validation. However, if you are checking the UPS.com SPF record:

$ dig +short TXT ups.com
"v=spf1 ip4:153.2.232.0/22 ip4:192.55.236.50/31 ip4:113.106.161.16 ip4:113.106.161.18 ip4:12.104.201.4/31 include:custhelp.com include:commerceplus.com.au -all"
 
There is no mention of 192.123.32.83. The header was added by the sender, not by the receiving mail gateway.
(you will have to check the "include" domains as well. I am leaving that as an exercise to the reader.)
 
If you implement SPF checking on your receiving e-mail gateway, you will have to make sure to first strip all existing SPF headers indicating SPF processing. Otherwise, the sender could add fake headers like the one above.
 
 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

0 comment(s)
My next class:

Comments


Diary Archives