Saturday, October 6, 2018

Email spoofing



Email spoofing is the creation of email messages with a forged sender address. Because the core email protocols do not have any mechanism for authentication, it is common for spam and phishing emails to use such spoofing to mislead the recipient about the origin of the message.

Technical detail

When an SMTP email is sent, the initial connection provides two pieces of address information: MAIL FROM: - generally presented to the recipient as the Return-path: header but not normally visible to the end user, and by default no checks are done that the sending system is authorized to send on behalf of that address.RCPT TO: - specifies which email address the email is delivered to, is not normally visible to the end user but may be present in the headers as part of the "Received:" header. Together these are sometimes referred to as the "envelope" addressing, by analogy with a traditional paper envelope, and unless the receiving mail server signals that it has problems with either of these items, the sending system sends the "DATA" command, and typically sends several header items, including:


From: Joe Q Doe < joeqdoe@example.com > - the address visible to the recipient;

but again, by default no checks are done that the sending system is authorized to send on behalf of that address.

Reply-to: Jane Roe < Jane.Roe@example.mil > - similarly not checked

and sometimes:

Sender: Jin Jo < jin.jo@example.jp > - also not checked.

The result is that the email recipient sees the email as having come from the address in the From: header; they may sometimes be able to find the MAIL FROM address; and if they reply to the email it will go to either the address presented in the From: or Reply-to: header - but none of these addresses are typically reliable, so automated bounce messages may generate backscatter.


Use by spam and worms

Malware such as Klez and Sober and many more modern examples often search for email addresses within the computer they have infected, and use those addresses both as targets for email, but also to create credible forged From fields in the emails that they send, so that these emails are more likely to be opened.

For example:

Alice is sent an infected email which she opens, running the worm code.

The worm code searches Alice's email address book and finds the addresses of Bob and Charlie.

From Alice's computer, the worm sends an infected email to Bob, but forged to appear to have been sent by Charlie.

In this case, even if Bob's system detects the incoming mail as containing malware, he sees the source as being Charlie, even though it really came from Alice's computer; meanwhile Alice may remain unaware that her computer has been infected.


Fooling media

It has happened that the media printed false stories based on spoofed e-mails.

In October 2013, an e-mail which looked like it was from the Swedish company Fingerprint Cards was sent to a news agency, saying that Samsung offered to purchase the company. The news spread and the stock exchange rate surged by 50%. It was later discovered the e-mail was a fake.

Legitimate use

In the early Internet, "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, these sorts of "legitimate" uses fell out of favor.

When multiple software systems communicate with each other via email, spoofing may be required in order to facilitate such communication. In any scenario where an email address is set up to automatically forward incoming emails to a system which only accepts emails from the email forwarder, spoofing is required in order to facilitate this behavior. This is common between ticketing systems which communicate with other ticketing systems.

The effect on mailservers

Traditionally, mail servers could accept a mail item, then later send a Non-Delivery Report or "bounce" message if it couldn't be delivered or had been quarantined for any reason. These would be sent to the "MAIL FROM:" aka "Return Path" address. With the massive rise in forged addresses, Best Practice is now to not generate NDRs for detected spam, viruses etc. but to reject the email during the SMTP transaction. When mail administrators fail to take this approach, their systems are guilty of sending "backscatter" emails to innocent parties - in itself a form of spam - or being used to perform "Joe job" attacks.

Identifying the source of the email

Although email spoofing is effective in forging the email address, the IP address of the computer sending the mail can generally be identified from the "Received:" lines in the email header. In many cases this is likely to be an innocent third party infected by malware that is sending the email without the owner's knowledge.

Countermeasures

The SSL/TLS system used to encrypt server-to-server email traffic can also be used to enforce authentication, but in practice it is seldom used, and a range of other potential solutions have also failed to gain traction.

However a number of effective systems are now widely used, including:

  • SPF
  • Sender ID
  • DKIM
  • DMARC

Although their use is increasing, estimates vary widely as to what percentage of emails have no form of domain authentication: from 8.6% to "almost half". To effectively stop forged email being delivered, the sending domains, their mail servers, and the receiving system all need to be configured correctly for these higher standards of authentication.

As modern countermeasures prevent spammers from spoofing the envelope-from address, many have moved to utilising the header-from address as seen by the recipient user rather than processed by the recipient MTA. Proprietary implementation beyond the scope of the SPF schema is required to protect against certain header-from spoofing implementations.

© From Wikipedia, the free encyclopedia

Tuesday, February 4, 2014

Backscatter

Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is incorrect automated bounce messages sent by mail servers, typically as a side effect of incoming spam.

Recipients of such messages see them as a form of unsolicited bulk email or spam since they were not solicited by the recipients, are substantially similar to each other and are delivered in bulk quantities. Systems that generate email backscatter can end up being listed on various DNSBLs and be in violation of internet service providers' Terms of Service. Backscatter occurs because worms and spam messages often forge their sender address, and mailservers configured by naive administrators send a bounce message to this address.

Measures to reduce the problem include avoiding the need for bounce message by doing most rejections at the initial SMTP connection stage; and sending bounce messages only to addresses which can be reliably judged to have not been forged.

Contents

1 Cause
2 Reducing the problem
2.1 Preventing email address collection
2.2 Connection-stage rejection
2.3 Checking bounce recipients
2.4 Filtering backscatter
3 See also
4 References
5 External links

Cause

Authors of spam and viruses wish to make their messages appear to originate from a legitimate source to fool recipients into opening the message so they often use web-crawling software to scan usenet postings, message boards, and web pages for legitimate email addresses.
Due to the design of SMTP mail, recipient mail servers receiving these forged messages have no simple standard way to determine the authenticity of the sender. If they accept the email during the connection phases then, after further checking refuse it - for example because they believe it to be spam they will use the (potentially forged) sender's address to attempt a good-faith effort to report the problem to the apparent sender.

Mail servers can handle undeliverable messages in three fundamentally different ways:

Reject. A receiving server can reject the incoming email during the connection stage while the sending server is still connected. If a message is rejected at connect time with a 5xx error code then the sending server can report the problem to the real sender cleanly.

Drop. A receiving server can initially accept the full message, but then determine that it is spam, and quarantine it - delivering to "Junk" or "Spam" folders from where it will eventually be deleted automatically. This is common behaviour, even though RFC 5321 says: "...silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate..."

Bounce. A receiving server can initially accept the full message, but then determine that it is spam or to a non-existent recipient, and generate a bounce message back to the supposed sender indicating that message delivery failed.
Backscatter occurs when the "bounce" method is used, and the sender information on the incoming email was that of an unrelated third party.

Reducing the problem

Every step to control worms and spam messages helps reduce backscatter, but other common approaches such as those in this section also reduce the same problem.

Preventing email address collection

It is common to attempt to obscure email addresses in a manner that is not easily machine-readable. Several methods are available, such as simply not using a standard text format (john (at) example.com) or using a bitmap image of the address rather than raw text. More complex address obscuration methods are available, such as encoding the addresses using a substitution cipher, embedded as program code within a tiny javascript or Adobe Flash program for each address, which when clicked, opens a temporary window and sends the decoded mailto: address to the local email client, but all such obscuration methods can potentially be attacked by spammers in the same manner as CAPTCHAs.

Connection-stage rejection

During the initial SMTP connection mailservers can do a range of checks, and often reject email with a 5xx error code while the sending server is still connected. Rejecting a message at the connection-stage in this way will usually cause the sending MTA to generate a local bounce message or Non-Delivery Notification (NDN) to a local, authenticated user.
Reasons for rejection include:

- Recipient validation
- Anti-forgery checks such as SPF, DKIM or Sender ID
- Servers that do not have a forward-confirmed reverse DNS entry
- Senders on block lists.
- Temporary rejection via greylisting methods

Mail transfer agents (MTAs) which forward mail can avoid generating backscatter by using a transparent SMTP proxy.

Checking bounce recipients

Mail servers sending email bounce messages can use a range of measures to judge whether a return address has been forged.

Filtering backscatter

While preventing backscatter is desirable, it is also possible to reduce its impact by filtering for it, and many spam filtering systems now include the option to attempt to detect and reject backscatter emails as spam. In addition, systems using schemes such as Bounce Address Tag Validation "tag" their outgoing email in a way that allows them to reliably detect incoming bogus bounce messages.

© Wikipedia, the free encyclopedia