Hi Everyone,
For those of you who follow our blog, you will notice that there haven’t been any new posts since early July. Sorry for the lack of content. We have been extremely busy pushing out a new release of MailChannels Outbound (our transparent outbound spam filtering solution for ISPs) and are getting ready to launch a revised web site in the near future.
Hang in there – we’ll have some new blog content soon.
Regards,
Ken Simpson
CEO, MailChannels
Tags: announcement
If you’re unlucky enough to be operating a mail server within Amazon.com’s Elastic Compute Cloud (EC2), you’ve probably had your share of problems sending email. At various times, Trend Micro’s MAPS+ service, the Spamhaus PBL, and other block lists have listed Amazon’s entire IP space, causing delivery problems for all Amazon EC2 customers regardless of their individual IP reputation.
The latest salvo in this reputation war comes to us from SORBS (aka, “Spam and Open Relay Blocking System”). SORBS has listed the entire Amazon EC2 IP address space as a source of spam and are sending out the following message to anyone who attempts to get their EC2 IP address de-listed:
From: SORBS Support (Matti Meikäläinen) <payments@support.sorbs.net>
You are an innocent party that has been included in an escalated listing against your service provider. Hints for who that might be can usually be found in WHOIS.
You are not required to address the issue in any way as it is overwhelmingly likely that the entry was not generated because of your actions. It is also the case that there is nothing that you, as a customer of the listed provider, can do about it. The listing will not be removed until your service provider successfully addresses it in direct contact with SORBS.
Please take this issue up with your service provider.
Note that it is possible that (and the volunteer sending you this form letter response hasn't even checked whether) your service provider is already in communication with SORBS. If they are and the listing persists regardless, they have either not yet addressed the issue to our satisfaction or something else is holding up the matter.
--
Matti
SORBS volunteer
SORBS and others have perfectly understandable reasons for listing Amazon EC2’s IP space – namely, there are a lot of spammers operating within Amazon EC2 and Amazon has so far not been able to get the problem under control. Their response to abuse complaints has also been slower than what the anti-abuse community would like.
I know that Amazon has good people working on fixing this problem. The SORBS listing is a sign that they perhaps need to work a bit harder, regardless of what anyone’s opinion of SORBS might be.
Tags: amazon, amazon ec2, blacklist, blacklists, blocklist, ec2, sorbs
We recently took a look at about 9 million delivery attempts through one of our outbound spam filtering customers’ systems and compiled a list of the most common spam connection rejection messages. I’ll share the list with you later in this blog post. But first, a bit of technical background for the uninitiated.
Most mail servers are configured to reject connections from IP addresses that appear on a black list. A notable exception to this would be Google, who through the sheer might of their infrastructure appear to accept connections from anyone, perhaps in order to beef up their spam folder size (to make it appear like they are doing more than they really are to reduce spam). In any case, if your SMTP connection is rejected because your IP address is found on a blacklist, you will get an error message from the receiving mail server that looks like the following:
Mail from 192.0.32.10 not allowed - 5.7.1 [BL23] Connections not accepted from IP addresses on Spamhaus XBL; see http://postmaster.yahoo.com/errors/550-bl23.html [550]
This rejection message is packaged up into a non-delivery receipt by your mail server, which sends this to your mailbox. You then hopefully click on the link, read Yahoo’s excellent error message documentation, and then take steps to have your IP address removed from the Spamhaus XBL as instructed.
I wanted to see which messages were the most popular, so I used our powerful log indexing system to pull out an hour’s worth of rejection notices. I then ran these through a very simple Map-Reduce script to count up the error responses, stripping out random variations like IP addresses and transaction IDs. What resulted is the following list of the world’s most popular blacklists — at least, from the perspective of error responses:
25% 5.7.1 [BL21] Connections will not be accepted from 1.2.3.4
10% Mail from 1.2.3.4 not allowed - 5.7.1 [BL23] Connections not accepted from IP addresses on Spamhaus XBL; see http://postmaster.yahoo.com/errors/550-bl23.html [550]
8% You are not allowed to connect.
8%
5% Service unavailable; Client host [1.2.3.4] blocked using Trend Micro RBL+.Please see http://www.mail-abuse.com/cgi-bin/lookup?ip_address=1.2.3.4
3% Mail from 1.2.3.4 not allowed - 5.7.1 [BL21] Connections not accepted from IP addresses on Spamhaus PBL; see http://postmaster.yahoo.com/errors/550-bl21.html [550]
3% IP:1.2.3.4 - A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)
2% Transaction failed. For explanation visit http://freemail.web.de/reject/?ip=1.2.3.4
2% No SMTPd here
1% 5.7.1 5.7.1 Client host rejected: Dynamic IP addresses are blocked. Please contact your email provider.
1% Denied by policy
1% Email from 1.2.3.4 is currently blocked by Verizon Online's anti-spam system. The email sender or Email Service Provider may visit http://www.verizon.net/whitelist and request removal of the block. 100604
1% RBL rejection: http://www.spamhaus.org/query/bl?ip=1.2.3.4
1% 5.5.0 Improper use of SMTP command pipelining
1% Mail from 1.2.3.4 not allowed - VS98-IP1 deferred - see http://help.yahoo.co.jp/help/jp/mail/anti-spam/anti-spam-24.html
1% 5.7.1 CCRX 1.2.3.4: Connection refused. Your IP address is blocked(anti-spam). If you need [truncated]
1% 5.7.1 service refused. Client host 1.2.3.4 blocked for spamming issues. Adresse IP source 1.2.3.4 bloquee pour incident de spam. Ref http://r.orange.fr/r/Oassistance_adresserejetee .
1% Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=1.2.3.4
1% 5.7.1 service refused. Client host 1.2.3.4 blocked for spamming issues. More information available at http://help.orange.c [truncated]
1% 5.7.1 Service unavailable; Client host [1.2.3.4] blocked using Trend Micro RBL+.
I’m amazed at how dominant Yahoo is in this list. Perhaps we chose a window of time during which this particular ISP network was hammering them especially hard in preference to the other networks.
Tags: blacklists, google, outbound, outbound spam, spam, spamhaus, yahoo
One of the things that we keep track of with Traffic Control is the percentage of SMTP connections which end without the sender issuing a QUIT command as required by RFC 5321. Because the QUIT command is required by the RFC, it’s possible to reject and prevent delivery of messages from senders who violate this requirement. The impact on legitimate senders is extremely low, because all known legitimate MTAs properly issue a QUIT.
For a very long time, the percentage of connections that did not issue QUIT hovered around 0.25%. But for some reason, in the past day this figure has shot up. The graph below details this development:
This graph shows a recent spike in the percentage of connections passing through Traffic Control servers which are not correctly issuing the QUIT command to end an SMTP connection.
The data is the same whether we look at individual customer sites, at inbound-only traffic, or at outbound traffic emanating from large ISP sites where we have installed Traffic Control for transparent outbound spam filtering. Any ideas as to why this is happening? Anyone else seeing this trend?
Tags: filtering, outbound, spam
"In the history of cryptography, the bombe was an electromechanical device used by British cryptologists to help break German Enigma-machine-generated signals during World War II. The bombe was designed by Alan Turing, with an important refinement suggested by Gordon Welchman. The bombe was named after, and inspired by, a device that had been designed in 1938 by Polish Cipher Bureau cryptologist Marian Rejewski, and known as the "cryptologic bomb" (Polish: "bomba kryptologiczna")."
In my two previous posts, I wrote about how the Rustock botnet is now sending a great deal of spam via TLS-encrypted connections and the variety of problems this new trend in spamming activity is causing and will cause for the Internet community. I mused that Rustock is probably encrypting spam because this allows its traffic to remain un-inspected by network analysis tools that perform man-in-the-middle analysis of SMTP traffic. In my second post, I discussed some of the problems that encrypted spam is causing for major email receivers, including increased TLS encryption load.
In this post, I will cover off a few things that receiving and sending networks can do to reduce the impact and amount of TLS-encrypted spam traversing the Internet. Fortunately, this is one of those spam problems where it’s not only up to the receivers to fix the problem.
What can email senders and receivers do to stop TLS-encrypted spam?
The only way to stop spammers from using TLS encryption is for the receiving mail server to tell the spambot that it does not support encryption. To understand how this is accomplished, let’s first have a look at how the ESMTP protocol advertises SMTP extension mechanisms, one of which is the STARTTLS command that initiates an encrypted session.
Advertising is not always a good idea
When an SMTP client (i.e. the machine sending email) issues the EHLO command at the start of an ESMTP connection, the SMTP server responds with a list of extension commands it supports. The SMTP client can then issue any of the commands listed. A typical response might look like the following:
250-ESMTP Server Ready
250-SIZE 0
250-DSN
250-STARTTLS
250 TLS
The STARTTLS command listed above allows the SMTP client to issue the command “STARTTLS”, after which a bunch of random looking garbage representing the actual TLS encrypted session is exchanged back and forth across the TCP connection.
If the mail server does not list STARTTLS when the EHLO command is issued, then the SMTP client may not send the STARTTLS command. This effectively prevents encryption from happening.
Interesting side-note: Most of the major consumer-oriented email receivers of the world do not ever advertise STARTTLS. I tested Hotmail, Gmail, Yahoo!, and AOL and found that none of them support TLS. Microsoft’s Exchange Hosted Services (formerly Frontbridge) does advertise STARTTLS. So does Symantec’s MessageLabs service. These are both enterprise-oriented services whose customers are most certainly more demanding of privacy and security than the typical customer of a consumer-oriented email service like Hotmail.
Senders and receivers both play a part
Email receivers who are concerned about encryption load can either completely disable TLS-encryption, or can be selective about whom they offer it to. If your email receiving system has a reputation system attached to it, you can implement a policy whereby STARTTLS is only advertised to IP addresses that have established a positive reputation – everyone else has to send in the clear, leaving less decryption burden on your CPUs.
Sending networks (e.g. ISPs, hosting companies, university campuses… basically anyone with lots of machines that can send on port 25) can also filter STARTTLS, assuming they have the right technology in place in the network. I don’t usually trumpet MailChannels technology in this blog, but in this case I’m going to go out on a limb and suggest that sending networks consider using a <a href=”/product/outbound.html”>transparent SMTP proxy</a> such as Traffic Control in the outbound path of their port-25 traffic. We – and a few others – can selectively block the STARTTLS response when senders from within the sending network are trying to connect to mail servers to deliver their deadly encrypted payload.
Conclusions
Incidentally, it seems like Rustock has calmed down w.r.t. sending encrypted spam of late. In the last 24 hours, only a tiny fraction of the connections emanating from our outbound filtering customer networks have been encrypted. Have we seen the end of this experiment or will we see a resurgence in the use of encryption by spammers?
Only time will tell.
Tags: encryption, outbound, rustock, spam, tls
Random non-email-spam-related aside: There have been widespread reports from the Asterisk open-source PBX community that spammers are attempting to gain access to Asterisk PBX through brute-force attacks originating from hosts within the Amazon EC2 cloud computing environment. The Asterisk-users mailing list has an active discussion on the topic.
Some thoughts from the email spam perspective:
- The VoIP community seems to be responding (and quickly) with blocking tools as a first line of defense against these attacks. How long will it be before spammers get the message and lower their per-IP volume to evade detection as they have done with email spam?
- When will we see RBLs emerging to assist with this problem?
- Amazon seems to be handling the abuse reports poorly – at least that’s the perception of the Asterisk users. When will the community get together to establish a VoIP abuse reporting framework similar to ARF?
- Is this problem affecting only the open source PBX crowd? Many of the Asterisk users seem to be running Asterisk on DSL connections etc.. It’s unlikely that vendors will help them.
That’s all for now – comments welcome!
Tags: amazon, asterisk, cloud computing, ec2, spam, voip
By 1943, Bombes began arriving at the Navy's Nebraska Avenue Communications Annex at a rate of four per week. The WAVES in Dayton began transferring with the machines and were trained to operate the Bombes. By the end of the war, 121 Bobles ran 24 hours per day, searching for Enigma rotor settings. The machines could search 456,976 setting in 20 minutes.
Last week I blogged about the recent surprising rise in the volume of TLS-encrypted spam sent by botnets (primarily the Rustock botnet). This week I’d like to discuss some of the problems caused by TLS-encrypted spam – for both receivers of email, and for service providers whose customers have the ability to send on port 25.
For receivers: More encryption means higher load, and that’s about all
Probably the most noticeable effect on email receivers caused by an increase in encryption of spam will be higher than normal load on external mail gateways. Decryption of TLS-encrypted SMTP sessions eats up a great deal more CPU than receiving email over a non-encrypted session. There are reports (although I can’t provide sources due to confidentiality requirements) of the increased load from TLS-encrypted spam causing major disruptions within some of the largest email receiving entities.
As more spam bots take advantage of TLS encryption, we fully expect that the load issues seen by the largest receivers will spread to large enterprise installations and university campuses. But small receivers will see no noticeable impact even if 100% of spam is encrypted.
For sending networks: Can’t stop what you can’t see
Sending networks are even more helpless in the face of TLS-encrypted spam – at least when it comes to stopping spam from leaking out of their networks and doing the “right thing” for the rest of the Internet. TLS ensures that sending networks cannot look at the content of spam messages as they exit the network, unless the sending network wishes to “break” the SSL encryption by responding to connections with a certificate that senders will find does not match the intended receiving domain. If sending networks can’t inspect messages to look for spam, then they can’t stop the spam from going out.
What to do about TLS-encrypted spam?
In my next post, I will postulate on a few potential counter attacks to TLS-encrypted spam – for both sending networks and receivers. Until then, please write to let us know what you’re seeing out there.
Tags: encryption, outbound, spam, ssl, tls
A US Navy WAVE sets the Bombe rotors prior to a run
Encrypted spam is on the rise
In mid-December we noticed a substantial increase in the percentage of encrypted SMTP sessions exiting the networks for which we provide transparent outbound spam filtering. Working with our colleague Terry Zink at Microsoft (blog), we found that the increase in TLS was almost solely the result of a change in the way the Rustock botnet operates.
TLS is normally used by legitimate email users to connect to external mail relays for the purpose of delivering mail. Even though it’s more ideal to connect using port 587 (the message submission port), many users still contact their corporate and other outbound mail servers on port 25, and encrypt these connections using TLS to prevent snooping or modification of message content.
But why?
But why would spammers want to use TLS? It seems at first glance to be a wasteful expenditure of CPU resources to encrypt each SMTP connection, and there is no evidence that we can find that suggests TLS-encrypted messages receive priority treatment on receiving systems.
Our theory
Well, I have a theory. As MailChannels and others increasingly deploy transparent SMTP filtering systems like Traffic Control, spammers are increasingly unlikely to succeed in getting their email delivered if the content can be inspected as it flows out of the source network. Systems like Traffic Control intercept the spam, read its content, and then apply filtering techniques to get rid of it so that it never even reaches its intended destination.
By encrypting spam connections, the authors of the Rustock botnet have bought themselves a healthy advantage against these outbound filtering systems, which now can no longer inspect the content because it is encrypted.
What percentage of spam is TLS-encrypted?
So now let me share some data to illustrate just how large of a problem this has become. If we look at a slice of the traffic emanating from one of the world’s largest carriers, we see that there is now more TLS-encrypted traffic than non-TLS encrypted, as shown in the following chart of last week’s data:
Chart of encrypted vs. non-encrypted SMTP sessions emanating from a major carrier's subscriber network during the week of March 22, 2010 - unspecified volume units
Who gets the most TLS-encrypted spam?
Taking a look at the most-spammed Class-C subnets in the last few minutes reveals a few familiar victims and some “noise” ones like Fidelity Financial:
OrgName: Postini, Inc.
OrgName: Postini, Inc.
OrgName: Postini, Inc.
OrgName: TREND MICRO INCORPORATED
OrgName: Postini, Inc.
OrgName: Postini, Inc.
OrgName: INFOCROSSING, INC.
OrgName: Fidelity National Financial Inc.
OrgName: INFOCROSSING, INC.
OrgName: Postini, Inc.
- Google Postini
- Google Postini
- Google Postini
- Trend Micro
- Google Postini
- Google Postini
- InfoCrossing (WiPro)
- Fidelity National Financial
- InfoCrossing (WiPro)
- Google Postini
The Google result is not surprising because Google’s services host email for literally millions of businesses. InfoCrossing is an India-based IT services company that hosts email for business customers around the world. And Trend Micro offers a variety of hosted email security services. Fidelity is likely just a random anomaly (i.e. the spammers chose to target it during this particular chunk of time).
In my next post, I will dive a little deeper into the problems caused by TLS-encrypted spam. Following that, I will discuss potential next steps for the email security industry to help deal with this issue.
Tags: encrypted, encryption, google, postini, spam, ssl, STARTTLS, tls, trend micro
MailChannels has observed a webmail abuse attack that hit Google Mail (Gmail) users and has not been publicly disclosed by Google as of Friday.
As with most targeted attacks, the intruders gain access to Gmail accounts and send short bursts of emails in response to Craigslist classified ads. These spoofing attacks successfully masquerade as a legitimate Gmail user, leading the target to fall for the trap and click a link to download a toolbar. The exploitation takes place when the malware is downloaded and installed, using a vulnerability in Microsoft’s Internet Explorer.
How do I know if my account was broken into?
Craigslist users may reply back to falsified inquiries or Gmail users may discover approximately 10 emails from Craigslist Remailer Daemon stating:
“We’ve received too many mails from johnsmith@gmail.com in a short time span. Sorry, but no messages from johnsmith@gmail.com will be relayed for 24 hours.”
A quick look at the Gmail Sent folder will confirm that on average 30 emails were sent from the compromised account in a 5 minute time period. This occurs at a time when the account is idle and the legitimate user is not logged in.
One hijacked Gmail user had this to say in the Gmail Help forum:
“I looked up ‘recent account activity,’ and there has indeed been two separate episodes of access into my gmail account that originated from two separate IP addresses, one in US and one in Saudi Arab. And needless to say both access times were correspondent to the two lots of spamming episodes.”
What is in the email content?
Gday,
found the Ad you put up on cl titled – “End Table with drawer” and I’m quite interested in getting this but I am not too confident if it’s the similar type that my cousin is after. Here’s a demo that I was able to cpy from my brother’s Macbook URL1 or try URL2. Can you please ensure its the similar type and get back to me as soon as possible. I’m willing to pay a little more than what you put on for sale as long it meets the Vid description and you can put it on hold for me.
Kind
Regards
Sonya.
The URLs are obfuscated using URL shortener “short.to”.
What if I’m the targeted seller of a Craigslist item?
The dead giveaway is that the email is signed by a different name from the sending email address. For example, the email will be signed at the bottom by Jessica, Julie or Sonya but the human-readable name is “John Smith” from “johnsmith@gmail.com”. Of course, do not click any shortened URLs from untrusted sources.
What can users do?
It is not believed to be widespread at this time but it is good practice to update your security questions and create a new, stronger password every few months.
Stay connected to MailChannels by following us on Twitter. We will continue to provide updates on this event if there is anything of interest.
Tags: abuse, gmail, spoofing
January 4th, 2010
Posted in Uncategorized
Greg Troxel reported on the SpamAssassin users mailing list today that he had received the first spam message sent via IPv6 (the successor to IPv4, the Internet Protocol addressing system).
The anti spam community is very concerned about IPv6 because its enormous address space will enable spammers to have access to a virtually unlimited number of IP addresses, rendering traditional “black lists” obsolete. When spammers start sending through IPv6 in earnest, receivers will have to rely on reputation-based whitelisting, treating new IPv6 addresses with a great deal of suspicion until they establish themselves to be trustworthy.
Could this be the end of Spamhaus and other venerable blacklists? Not so fast. It will take decades for IPv4 to be phased out in favour of the new standard. And until that happens, blocking will remain an indispensable technique for stopping spam.
The raw message looks like this (
Link):
Return-Path: X-Spam-DCC: _DCCB_:_DCCRX-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fnord.ir.bbn.comX-Spam-Level:X-Spam-Status: No, score=-4.8 required=1.0 tests=ALL_TRUSTED,AWL,BAYES_95,DATE_IN_PAST_12_24,TVD_PH_SUBJ_META autolearn=no version=3.2.5X-Original-To: gdt@ir.bbn.comDelivered-To: gdt@ir.bbn.comReceived: from vilab.hit.edu.cn (unknown [IPv6:2001:da8:b800:228:5054:abff:fe10:8e4c])(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))(No client certificate requested)by fnord.ir.bbn.com (Postfix) with ESMTPS id 86A4C5489for ; Sun, 3 Jan 2010 22:17:03 -0500 (EST)Received: from vilab.hit.edu.cn (localhost [127.0.0.1])by vilab.hit.edu.cn (Postfix) with ESMTP id 8BEF2B10DE1;Sun, 3 Jan 2010 21:59:27 +0800 (CST)From: "UN-HABITAT" Reply-To: ups.deliveryservice@hotmail.comSubject: NoticeDate: Sun, 3 Jan 2010 21:59:27 +0800Message-Id: <20100103125409.m77170@vilab.hit.edu.cn>X-Mailer: OpenWebMail 2.53-B2DX-OriginatingIP: 78.138.3.236 (jcsun)MIME-Version: 1.0Content-Type: text/plain;charset=utf-8To: undisclosed-recipients:;X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fnord.ir.bbn.com [0.0.0.0]); Sun, 03 Jan 2010 22:17:05 -0500 (EST)
Your Attention,
After several attempt to reach you, I deemed it necessary and urgent tocontact you with your email and to notify you finally about theoutstanding settlement of your compensation which is being given out bythe United Nations Human Settlements Programme. This compensation is beingmade to all victims that have lost their money through any onlinetransactions or as a result of Scam activities. It has come to our noticethat many of you have lost your money by falling victim to some internetfraudsters.
The United Nations Human Settlements Programme, UN-HABITAT, is the UnitedNations agency for human settlements. It is mandated by the UN GeneralAssembly to promote humanly, socially and environmentally with the goal ofproviding adequate shelter for all.
As a result of this scam activities spreading over the internet, theUnited Nations Human Settlements Programme, UN-HABITAT have decided to getdetails of most victims who were previously scammed by these fraudsters.
This Human Settlements Programme is design to compensate every one of youwith the sum of $500,000.00 USD to help settle all your debts and start anew business.
We have concluded all the necessary arrangements towards the release ofyour settlement Check sum of $500,000.00 USD with the financial committeeof the United Nations Human Settlements Programme in collaboration withthe United Parcel Service LTD (UPS) Nigeria, to deliver the check sum of$500,000.00 USD which is registered with Ref No: UN014-0157/UPS-UN-HABITATto your Compensation Check Parcel.
You are therefore to contact the United Parcel Service LTD (UPS) Nigeria,with the below information in order to claim your compensation check. Take
note that we have not pay for the shipment of your Check Parcel as youwill be required to pay the shipping/handling charges for yourcompensation check to be deliverd to you.
You are required to contact the UPS Courier Service with the belowinformation
Name:Delivery Address:Direct Phone number:Sex:Country:
=================================United Parcel Service Nigeria LTDPlot 781 Emeka Anyaoku StreetArea Eleven GarkiFCT-AbujaNigeria.Tel: +234-813-643-9535Email: ups.deliveryservice@hotmail.com=================================
Accept our regards.
Higgins A. DeniseUN-HABITAT Information Office
Tags: blacklist, IPv4, IPv6, spam, spamhaus
POST