Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: SPF

{Quick Post} Mail headers

I know this topic has been discussed in various venues under the flag of OSINT, but I came across a nice example that I thought was worth sharing… even if just to re-iterate the point!

Following an email to a unnamed company, threw up a couple of interesting facts that companies should really be aware of. Information disclosure is always present, but email headers and failure notices are a goldmine of information if you take the time to dig into them.

Note: nothing I’m posting here is private or restricted. Anybody sending an email to the public relations email address will receive the same information. Don’t shoot the messenger!

Diagnostic information for administrators:

Generating server: democorp.CORP

group@democorp.com
#550 5.7.1 RESOLVER.RST.AuthRequired; authentication required ##

Original message headers:

Received: from mx4.dfw1.democorp.com (10.7.9.76) by smtpout.democorp.com
 (10.12.120.25) with Microsoft SMTP Server id 14.2.298.4; Mon, 9 Jul 2012
 09:14:34 -0500
Received-SPF: Pass (mx4.dfw1.democorp.com: domain of
  xyz@c22.cc designates 209.85.214.180 as permitted
  sender) identity=mailfrom; client-ip=209.85.214.180;
  receiver=mx4.dfw1.democorp.com;
  envelope-from="xyz@c22.cc";
  x-sender="xyz@c22.cc"; x-conformance=spf_only;
  x-record-type="v=spf1"
Received-SPF: None (mx4.dfw1.democorp.com: no sender
  authenticity information available from domain of
  postmaster@mail-ob0-f180.google.com) identity=helo;
  client-ip=209.85.214.180; receiver=mx4.dfw1.democorp.com;
  envelope-from="xyz@c22.cc";
  x-sender="postmaster@mail-ob0-f180.google.com";
  x-conformance=spf_only
X-SBRS: 4.4
X-SenderGroup: None
X-MailFlowPolicy: $ACCEPTED
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkBAHvm+k/RVda0kGdsb2JhbABCA4JKpEeHVgGIfAgiAQEBAQkJDQcUBCOCIAEBAQEDEgIsAQE4DxYGAwECLyISAQUBEgIIBw4ECBqFb4F8C45NjioJA4pmhC4BBY5kBotAgmuDIYspihCBEoUwhESDIj6EAIFd
Received: from mail-ob0-f180.google.com ([209.85.214.180])  by
 mx4.dfw1.democorp.com with ESMTP/TLS/RC4-SHA; 09 Jul 2012 09:14:33 -0500
Received: by mail-ob0-f180.google.com with SMTP id uo19so20894072obb.11
        for <group@democorp.com>; Mon, 09 Jul 2012 07:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=c22.cc; s=c22;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        bh=UTOmJBpa86TfxGjU5tQXis28YV6Sw/gTVT6wUE6UMws=;
        b=eSSc9Wsxr4Tn1WRIl6iQX8C67WGREgXDr1/U8r4vSfUTMRxXbyH4pYYdGR08yt8RQi
         iC1AkTr1hNqvBUJ4mt5ELhfW8NPwfRD9W2DShyFS2engogMPg6EKt6DuWuCy0hLRJOzN
         hmPSk/1VTuegKJa8nIAwTW5I/hCL8EkJKtn1M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:x-gm-message-state;
        bh=UTOmJBpa86TfxGjU5tQXis28YV6Sw/gTVT6wUE6UMws=;
        b=X+t+5o5x/V/kpc1b2fMKr31W1wj5jLnkEfhwjLVEqLrLMczv2WjyI0VCDXDmBLJQ7R
         DvDRMRnB+Hwk/xhDwOcogOvHucrXk3wCrgAGZqnFbKgqjcoR99OnRIaSgFmYeHE1lNmN
         twOHoamsRoBmeh8xtuCzt24WdcBiSrw9VzugUu2xJ+3/9kWrJijqk0I4VaFDrNIeu6TH
         DmGIEtZojB0MLLZC/a4x2Bg7AhnKElP0AQTnOihXw+CuoJcbI1GzIdCkB3mBHtnvPW9Z
         GmtqoKjvwvxaYOlOPkM3zKilOJ4oc8QywG89sFDT7+zs3zaL53JPlmJGpzV3rBjmOY4J
         eQ9g==
Received: by 10.182.216.99 with SMTP id op3mr15297272obc.30.1341843273175;
 Mon, 09 Jul 2012 07:14:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.209.3 with HTTP; Mon, 9 Jul 2012 07:14:12 -0700 (PDT)
In-Reply-To:
References: <CAOXycj0yy-qAmWUz6PpqjAVX=XOV3=eEJN3VU=iQsZfj_zDH0g@mail.gmail.com>
From: Chris John Riley <xyz@c22.cc>
Date: Mon, 9 Jul 2012 16:14:12 +0200
Message-ID: <CAOXycj2BvTr19Raa-qt4KbBo0QigNATR20VH9fwpKL3oJwQxdA@mail.gmail.com>
Subject: subject
To: <group@democorp.com>
Content-Type: multipart/alternative; boundary="f46d044786e7a4540a04c4663b39"
X-Gm-Message-State: ALoCoQkSGcaZiYEGGYIMbwVNAM5LTm/F/gFzBwRRIeWWGriOQ48yR0cwLsmbBD6aFt5YFVyrA+
Return-Path: xyz@c22.cc

Taking some of the more interesting points from the above message,  you can extract the obvious information such as internal IP range and the version of Exchange Server in use (14.2.298.4) from the first few lines of the error (lines 10-11).

Digging a little deeper however you can also extract some interesting information about the security in and around the email system (lines 32-35). This includes details on the use of TLS for email transfer (ESMTP/TLS/RC4-SHA), and a hint to the cipher (dependant on the support ciphers on the sender-side). What’s also interesting is the “Received-SPF” and “DKIM-Signature” (lines 13 and 36). In the case of SPF the remote mailserver is actively checking the SPF record and is performing a reverse lookup to check that the sending host is permitted to send email on behalf of the sending domain (c22.cc). In this case everything is fine, but it’s important to know if you’re performing an authorised pentest… especially if you’re phishing ;)

The last little bit of information you can squeeze out is the exposed “X-IronPort-Anti-Spam” and “X-SBRS” headers (lines 27-31). From this you can gather that the remote server is running IronPort and the email you sent scored a 4.4 on the IronPort’s anti-spam rating. Again, this is good for those tests where you’re phishing and need to see what score your emails are getting. Simply sending your prepared email to a non-existent (or in this case, failing) email address should net you some feedback on how good your phishing email is perceived by the IronPort.

The “X-SenderGroup” and “X-MailFlowPolicy” headers (lines 28 and 29) are also added in by the Cisco IronPort, so might be a source of interest!

My suggestion to companies is to check the data that your mailservers are exposing through failure notifications… even if you can’t stop this data from leaving your network via configuration tweaks, it’s at least good to know what information you’re providing to attackers!

Stop spoofing me !!!

I’ve been fighting the good fight against spammers for a few months now on and off. Not the usual fight however. This time my domain is the problem, as some nice spam-bot out there on the web has taken a liking to my domain and wants to use it as the source of it’s evil advertising campaigns. It’s annoying really, as every time this spam-bot emails to the wrong address, I end up getting the bounce message. A couple a day in July, turned quickly into a few hundred a day in August. This weekend I finally had the chance to sit down and do some research on what I can do to make this spam-bot go away and start spoofing some AOL addresses again. The answer I came across was SPF.

Ok, I guess people now are saying WTF is SPF when it’s at home. SPF is “Sender Policy Framework”, and it’s aim (if used) is to provide a way for servers receiving email to check if the sender is who they’re supposed to be. This is achieved through the use of a TXT entry on the name-server used for your domain. This TXT entry tells the receiving server what IP address you’re emails should originate from, and if they don’t match, then dump the email on the floor. In the short-term, this may not solve my problem 100%, but if even 1 spam gets stopped because I’ve added this SPF entry, then in my view it’s a job well done. Maybe it’ll even force the spam-bot to move on to another domain without the SPF set.

How do you do this you say… well it’s easy. The details are discussed on the SPF homepage and include everything you’ll need to understand how it works and what to add. You can also use a number of automatic SPF creators on the web, including the one at openspf.org. As an example, my SPF entry (which you can find by doing an nslookup on my domain) is .:

v=spf1 a a:remote.c22.cc include:aspmx.googlemail.com ~all

Looks complex… but once you break it down, it’s not that hard to understand.

v=spf1 – is the version number of SPF supported

a – means that all A records for my domain are permitted to send email

a:remote.c22.cc – sets the remote.c22.cc CNAME as permitted

include:aspmx.googlemail.com – tells the server checking to lookup the SPF record for gmail as well

~all – is the catch-all rule, that says these are the only servers permitted

See, simple really. Most domains will have a simple SPF like v=spf1 a ~all or v=spf1 ip4:x.x.x.x ~all if you only have 1 publicly addressable mail server. Mine is currently more complex as I’m testing various solutions. However in the long run it’ll end up just as an include to the Google servers.

spf-logo-medium Is SPF going to stop SPAM… NO, probably not. But it’s going to make things a little harder for the evil spam-bots of the world. After all, if the legitimate domains are protected using something like SPF (or Microsoft’s version SenderID) then the spammers will need to setup a domain to send spam from. With improved communication in the industry, these domains will be quickly blacklisted. Of course spammers can get new domains constantly (at a cost) or use DNS poisoning to force the SPF records to be blank on set servers. However, SPF isn’t meant to be THE solution. It’s just another piece of the puzzle. After all the only real solutions to spam are to make it so hard to do that it’s no longer worthwhile, or educate those people still STUPID enough to think, ooh I can help a deposed Nigerian president AND earn money…. Sign me up.

Right now I’m not sure how much spam this SPF is stopping. After all, I’m not sure how much is being spoofed. Still, if the servers support SPF checking then I’m sure it’ll be doing some good. My suggestion, if you’ve got a domain, then spend 5 minutes to set an SPF to protect others from spam that might be spoofed from your domain in the future.

Follow

Get every new post delivered to your Inbox.

Join 132 other followers