1. IntroductionSpoofing is the action of making something look like something that it is not in order to gain unauthorized access to a user's private information. The idea of spoofing originated in the 1980s with the discovery of a security hole in the TCP protocol. Today spoofing exists in various forms namely IP, URL and Email spoofing.
Email Spoofing: Email spoofing may occur in different forms, but all have a similar result: a user receives email that appears to have originated from one source when it actually was sent from another source. Email spoofing is often an attempt to trick the user into making a damaging statement or releasing sensitive information (such as passwords).
Examples of spoofed email • email claiming to be from a system administrator requesting users to change their passwords to a specified string and threatening to suspend their account if they do not do this
• email claiming to be from a person in authority requesting users to send them a copy of a password file or other sensitive information
• E-mail spoofing is e-mail activity in which the sender address and other parts of the e-mail header are altered to appear as though the e-mail originated from a different source. Because core SMTP doesn't provide any authentication, it is easy to impersonate and forge emails. It is usually fraudulent but can be legitimate. It is commonly used in spam and phishing e-mails to hide the origin of the e-mail message. By changing certain properties of the e-mail, such as the From, Return-Path and Reply-To fields (which can be found in the message header), ill-intentioned users can make the e-mail appear to be from someone other than the actual sender. The result is that, although the e-mail appears to come from the address indicated in the From field (found in the e-mail headers), it actually comes from another source.
• Occasionally (especially if the spam requires a reply from the recipient, as in advance-fee frauds), the source of the spam e-mail is indicated in the Reply-To field (or at least a way of identifying the spammer); if this is the case and the initial e-mail is replied to, the delivery will be sent to the address specified in the Reply-To field, which could be the spammer's address. However, most spam emails (especially malicious ones with a trojan/virus payload, or those advertising a web site) forge this address too, and replying to it will annoy an innocent third party.
• Prior to the advent of unsolicited commercial email (spam) as a viable business model, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as open relays, this was a common practice. As spam email became an annoying problem, most of these "legitimate" uses fell victim to antispam techniques.
How to Avoid Email Spoofing??????1. Strong Website Authentication:This approach would require all users of legitimate e-commerce and e-banking sites to strongly authenticate themselves to the site using a physical token such as a smart card.
The positive aspects of this approach are:
• Even if a user falls for a phishing attack, a phisher can’t log into real site without the right physical token.
• Users are given a stronger sense of trust in their transactions with business web site.
The downsides of this approach are:
• User education
• Set up time delays
• Desktop software installation
• High management costs
• Potentially high cost per user
2. Mail Server AuthenticationThe Anti-Spam Research Group (ASRG) and the Anti-Spam Alliance have been investigating solutions to the growing spam problem based on authenticating sending mail servers. There are numerous technical proposals such as RMX for how this will work.
The positives of this approach are:
• Easy to configure at senders mail servers
• Makes it harder for phishers to be anonymous
• Legitimate business email can be better identified – lower spam false positives
The downsides of this approach are:
• Requires sender and recipient gateways to both use these methods
• SMTP sender is not visible to recipient
• From: address still can be spoofed and users can be fooled
• Will be a problem for anyone using a 3rd party emailing service
• Doesn’t accommodate email forwarding
3. Digitally Signed Email With Desktop VerificationThis approach is based on the use of the existing industry standard S/MIME, which is a secure email standard supported by most email client software that is in use in corporations today. Companies who are vulnerable to phishing attacks, such as financial institutions, payment processors and e-commerce vendors, would send their emails with a digital signature attached. Note that the digital signature would be attached at the outbound gateway, rather than requiring the individual sender to apply the digital signature. This automation at the gateway would further increase the adoption rate of such a solution. When users receive these digitally signed emails, their business email clients (e.g. Microsoft Outlook, Lotus Notes, Novell Groupwise, etc) will automatically verify the signature for authenticity. If an email arrives to a user that is either not signed, or the signature can not be verified, the user would know that it is not a genuine email from the sending bank or ecommerce provider.
The positives of this approach are:
• S/MIME is a standard in business email clients – would work without any additional software deployment to email users
• Makes the “From:” address impossible to spoof without detection
• Any phisher who digitally signs their email must register with a certificate authority – provides a stronger identity audit trail when prosecuting the phisher
• Legitimate business email can be better identified by end-users – provides better trust ` with customers
The downsides of this approach are:
• Recipients still have to inspect the “From:” address for misleading domains (e.g. a phishing email could have a valid digital signature with the email address of account.update@ebay.custservices.com. The end user would have to know that ebay.custservices.com is not in fact Ebay because ebay.com is not in the domain portion of the address.)
• Not all email clients support S/MIME (e.g. Hotmail, AOL, Yahoo! Mail, Outlook Web Access for Exchange 5.5)
• Recipients may not check certificate revocation status
4. Digitally Signed Email With GatewayVerificationSimilarly to Solution 3 proposed above, this approach uses the S/MIME standard for email that is widely available today. Instead of relying on the end user’s email client to verify the signature on the email, a gateway server at the mail relay level would verify the signatures before they were even received by the receiver’s email server. This approach would work well for ISPs and web email providers who wish to support signed email as a way to defeat phishing attacks.
The positives of this approach are:
• S/MIME is a standard today that is supported by many email gateways
• Makes the “From:” address impossible to spoof without detection
• Any phisher who digitally signs their email must register with a certificate authority – provides a
stronger identity audit trail when prosecuting the phisher
• Legitimate business email can be better identified by end-users – provides better trust with customers
The downsides of this approach are:
• Sender and recipient gateways must both understand S/MIME digital signatures
• Doesn’t prevent valid signatures from having misleading From: addresses (e.g. a phishing email could have a valid digital signature with the email address of account.update@ebay.custservices.com. The recipient gateway would likely pass the email on and the end user would have to know that ebay.custservices.com is not in fact Ebay because ebay.com is not in the domain portion of the address.)
