VKernel.co.uk – Your interface to the world

SPF – Sender Policy Framework

SPF can be used to allows software to identify messages that are or are not authorized to use the domain name in the SMTP HELO and MAIL FROM Return-Path commands, based on information published in a sender policy of the domain owner. Forged return paths are common in spam and result in backscatter. SPF is defined in RFC 4408. SPF is useful as it prevents spam as the email is not coming from an authorised domain, resulting in CIDR error returns to the sending party.

Shameless pull from Wikipedia on how to Implement SPF:

Implementation

Compliance with SPF consists of three loosely related tasks:

Publish a policy 

Domains identify the machines authorized to send e-mail on their behalf. Domains do this by adding additional records to their existing DNS information: every domain name that has an A record or MX record deserves a TXT record specifying the policy if it is used either in an email address or as HELO/EHLO argument.

Check and use SPF information 

Receivers use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.

Revise mail forwarding

Plain mail forwarding is not allowed by SPF. The alternatives are

• remailing, i.e. replacing the original sender with one belonging to the local domain,
• refusing, i.e. answering 551 User not local; please try <user@example.com>,
• whitelisting on the target server, so that it will not refuse a forwarded message, and
• Sender Rewriting Scheme, a more complicated mechanism that handles forwarding back-scatter back.

Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use. The records are laid out like this (in typical DNS-syntax):

example.org. IN TXT "v=spf1 a mx -all"

“v=” defines the version of SPF used. The following words provide mechanisms to use to determine if a domain is eligible to send mail. The “a” and “mx” specify the systems permitted to send messages for the given domain. The “-all” at the end specifies that, if the previous mechanisms did not match, the message should be rejected.

 

 

Tags: Email, Security, SPF

Matt on Acer Aspire One w/ Ubuntu – WiFi Fix after Suspend/Resume

Acer Aspire One: http://www.acer.com/aspireone/
Intel Atom: http://www.intel.com/technology/atom/index.htm
Ubuntu 8.10: http://www.ubuntu.com/
Performance Improvement for ubuntu on Aspire One: https://help.ubuntu.com/community/AspireOne

Anyway, this combination is awsome! The ease of use of ubuntu for day to day use, combined with the fact it’s still Linux for advanced hacking when needed, all in a tiny laptop package which makes it portable enough to throw in your bag and have it with you anywhere.

The default 802.11a/b/g card is an internal atheros miniPCI card as well, which means using the madwifi drivers the laptop supports wireless packet injection out of the box

There is however one issue I have had, and that is that wifi was broken after a suspend/resume (suspend/resume is damn fast). After a little playing around I have managed to fix this, my solution is below:

The solution is to unload the madwifi drivers on suspend, and reload them on resume.
you can do this manually after resuming by running the following commands as root:

/usr/local/bin/madwifi-unload
/sbin/modprobe ath_pci

This unloads all madwifi kernel modules, and then loads them again. The wifi should spring back into life.
However, this is nasty, so the following script will run these commands for you on suspend/resume:

Create a new file in /usr/lib/pm-utils/sleep.d called ‘06acerwifi’.
Chmod this to 755, and place the following into it:


#!/bin/sh
#

. “${PM_FUNCTIONS}”

unload_madwifi()
{
/usr/local/bin/madwifi-unload > /dev/null
}

load_madwifi()
{
/sbin/modprobe ath_pci > /dev/null
}

case “$1″ in
hibernate|suspend)
unload_madwifi
;;
thaw|resume)
load_madwifi
;;
*) exit $NA
;;
esac

Hope this helps someone!
//Matt

Tags: Acer, Acer Aspire, Ubuntu, Wifi

Matt on Root CA Spoofing

A proof of concept attack has been presented at 25C3 (http://events.ccc.de/congress/2008/) showing that it is possible to use the well known MD5 hash collision insecurity to create your own ‘Certificate Authority’ (CA) signing certificate which is already accepted as trusted by most of the major browsers.

This allows an attacker with this root CA key to sign any other certificates he wishes, and all of these will be trusted by client browsers.

Scenario: In the past, if you went to your online banking website and a certificate error appeared, you would suspect something was up, possably you were being Man-in-the-middled and you were being proxied through a malicious machine, or alternativley your DNS had been poisoned and the site you were looking at was not the real bank’s site. You knew this BECAUSE of the certificate error and the attacker could do nothing about it because he was not able to get the private key of the bank’s certificate, or have his own bank certificate pair signed by a signing authority. The attacker just had to hope the user just clicked ‘Continue anyway’ etc.

However now, the attacker basically has the public and private key for a root CA certificate installed in your browser, he can sign any certificate pair he wants, and it will be trusted. How do you differentiate now? when both the real bank and attacker bank site come up with a rosy green SSL bill of health?

Creation of such a certificate only works against certificate authorities that still use MD5 (RapidSSL was used in this particular exploit) and with the release of this information, I should hope that the number of CA’s using this == 0 in a very short while

This has been a very crude and technically lacking explanation, however I suggest you read the following link for a much more indepth step by step process on how this was carried out;

http://www.win.tue.nl/hashclash/rogue-ca/

//Matt

Tags: Root, Root CA, Spoofing