Santa Likely To Receive Over A Billion Spam Emails This Christmas!

You may not believe in Santa Claus, but surely you must believe in Wikipedia, and that's enough to read this post.

According to Wikipedia roughly 33% of the World's population are Christians, the World's population is currently around 6.6 billion, and the average life expectancy is 67 years. Let's assume that 80% of children believe in Santa Claus and on average stop writing to Santa Claus at around 12 years old. Now let's assume that 50% send an email to Santa requesting a new train-set or pony.

The number of emails Santa Claus will receive this year is (6.6 billion * 0.33 * 12/67 * 0.80 * 0.50) approximately 150 million emails from excited children. That's a lot of emails! Now let's assume that poor old Santa Claus has been too busy reading emails to install an email security solution. Since his email address is so well known (santa AT thenorthpole DOT com) and the spammers, who believe in him, know he reads all his email, he'll likely be receiving over a 90% spam rate.

If only 10% are legitimate email, he'll be looking at 1.5 billion emails, 1.35 billion of which are spam!

So as you're getting ready for Christmas, or whichever holiday you celebrate, spare a thought for Santa Claus.

Facebook e-mail address harvesting?

In November, I blogged on the fact that Social Networking sites, specifically LinkedIn, could be used in attempts to harvest personal information. A recent story on InformationWeek caught my attention since it relates to a Canadian company and involves an attempt to harvest data from Facebook. As e-mail address harvesting is key to a spam campaign, I feel this is very relevent to the Anti-Spam community. To quote from the article..

Facebook alleges that during the 15 day period between June 1, 2007 and June 15, 2007, the defendants tried to access information on Facebook's servers over 200,000 times using an automated script that attempted to harvest information from other Facebook users.The alleged information harvesting effort cost Facebook over $5,000, the legal filing claims, noting that the data accessed includes user names, passwords, network affiliations and e-mail addresses.

Facebook originally filed the lawsuit in June of this year against 10 unnamed companies but amended it last week to name three of the individuals and companies as defendants. It's paramount that Social Networking sites take security seriously if they are to maintain the trust of their userbase.

IBM on Spam and Phishing

IBM published their mid-year report for 2007 with details related to spam and phishing attacks. It's quite a long report so I picked out some of the points I found interesting.

There's a synergy between spam and virus activity since a wide spread virus has the ability to turn hundreds of thousands of personal computers into spam spewing zombies. The virus writers exploit vulnerabilities to gain control of a machine. IBM commented that "more than half of the vulnerabilities in the first half of 2007 would allow an attacker to gain access to the host after successful exploitation". An interesting point is that the top 3 vulnerability vendors in the first half of 2007 were Microsoft, Apple and Oracle.

As part of the spam analysis they looked at the average byte size of spam. This of course correlates with the surge in attachment spam over the past couple of years in the form of images, pdf's, mp3's etc.



They also provided a plot of the countries that host the spam websites:

PingedIn Update

Scott Chasin of MX Logic called to mention that our numbers for MX Logic seemed off (see the original post). Indeed they were. MX Logic is in fact doing better now than it was back in the summer. Google, however, is still moving way off the charts.

Some people also asked why the MessageLabs chart moves all over the place -- or indeed why any of the numbers move all over the place. The reason is that, for efficiency reasons, the PingedIn system only tries a certain number of times to contact the mail servers for each company in the database. If the DNS is slow, or not functioning for a particular domain, or if the receiving mail server doesn't want to talk to us, then we that ping is not recorded in the database, causing a downward blip in the chart.

Here's the new graph -- thanks to all of you who commented on the previous post:

Google Apps are Taking Off?

Some of you may be familiar with MailChannels' "PingedIn" service. Every night, we survey the mail servers of approximately half a million companies worldwide, using a proprietary algorithm to determine the kind of email server software they are using to receive email.

Recently I was reviewing historical data stretching back to mid-summer, when I noticed a strong trend:


The lime green line shows that there has been a 50% increase in the number of companies using Google to host their email. This is a really impressive rate of growth in what has been a fairly stagnant industry for the past few years.

Other interesting observations:

• The decline of software: more and more companies are outsourcing their edge email solution to someone else. The only exception we found to this rule was MXLogic, who appear to have lost about 5% of their customers since mid-summer (according to our data -- please don't sue us).
• The flattening of IronPort: There has been virtually no growth at all in IronPort's installed base since they were acquired by Cisco. That said, at least they haven't lost ground.
• Continuing high rate of churn: Not shown on the graph, but tracked by PingedIn is the rate at which companies move from one solution to another. We are continuing to see an approximately 20% annual churn rate in the email boundary market.

Now, even though Google's growth may appear spectacular, it should be taken with a grain of salt. There are more than 17,000 sites in our database running Barracuda email appliances. Google still has just 1800. But at their current rate of growth, Google should surpass Barracuda some time in 2010. By the same token, even though there are still 42,000 Sendmail sites in our database, at its current rate of decline, Sendmail will be all but extinct in 2015.

Okay, 2015 is a really long way away. Sendmail is going to be with us until the end of time.

Spammers in Space!

Did you know that some of the spam in your inbox has actually travelled to space?

It's true! A spammer can send the spam e-mail via satellite and it happens more often that you'd think. Ironically though it's typically the least sophisticated spam attacks that take such a sophisticated route to your inbox.

So how does exactly does it happen? In certain parts of the world, the telecommunications infrastructure is rather lacking. It would be overly expensive to provide cable internet to remote regions so an alternative is for providers to offer satellite internet. In Africa, for example there are many internet cafe's that provide internet access in this way.

You've probably seen a scam e-mail requesting the transfer of funds to Nigeria. Those e-mails are often sent by hand using real webmail accounts from internet cafes. Many of the large webmail providers track the IP address of the connecting host either by appending an X-Originating-IP header or with a Received header indicating it originated from the web. It's in this way we can identify the actual source of the sender and trace it back to a particular satellite internet provider.

Who could have predicted a spam problem?

E-mail began to develop in 1965 when a messaging system to allow users of a shared mainframe to communicate locally created. It wasn't until 1971 that Ray Tomlinson picked the @ symbol addressing convention to allow inter-networked machines to exchange messages. Oh and if you're wondering what the first e-mail he sent contained, he believes it was something along the lines of "QWERTYUIOP" but he can't quite remember. Perhaps because he couldn't check his sent items as it wasn't until 1972 when the first e-mail management program emerged. No wonder so many people in the sixties shared peace and love since they didn't have to deal with spam.

In the seventies e-mail was used primarily be researchers and government agencies. Although believe it or not, the Queen of England did send an e-mail in 1976 as part of a demonstration and was the first head of state to do so! At this time spam didn't exist unless you were referring to Spam of the meat variety. It was quite impressive then that in 1975, Dr. Jon Postel wrote the IETF document RFC706 related to the possibility of junk e-mail titled "On the junk mail problem" but figured it would be the result of a malfunctioning machine:

It would be useful for a Host to be able to decline messages from sources it believes are misbehaving or are simply annoying. If the Host/IMP interface protocol allowed the Host to say to the IMP "refuse messages from Host X", the IMPs could discard the unwanted messages at their earliest opportunity returning a "refused" notice to the offending Host.

He also went out to suggest black listing based on a frequency analysis of messages from a host:

A Host might make use of such a facility by measuring, per source, the number of undesired messages per unit time, if this measure exceeds a threshold then the Host could issue the "refuse messages from Host X" message to the IMP.

The first spam message didn't really appear until 1978 when the DEC marketing department sent a message advertising a seminar in California. In 1988, a person posted to multiple newsgroups asking for college fund donations. The term "spam" emerged in 1993 when usenet moderation software with a bug posted around 200 messages by accident. From 1994 onwards the spam problem continued to escalate to the situation we have here today where open relays and proxies were dropped in favor of compromised home user machines.

Does Sendmail Throttle?

The MailChannels TrafficControl product reduces spam by throttling the sender so that a spammer will eventually give up. If I explain this to a system administrator it's commonly met with the question "Doesn't Sendmail already Throttle?"

I can understand where the confusion arises since the term "throttle" is quite generic and can be applied to any type of restriction or limiting to a resource. So I thought it might be worthwhile explaining things further.

In the case of TrafficControl the entire SMTP conversation is drastically slowed down in both directions to emulate a slow connection. This means that a never before seen zombie sending an image spam e-mail of around 20kB could expect to transfer data at a rate of 15 bytes per second (configurable) which could mean having to hang around for 20 minutes or so. Since the system is designed with SMTP multi-plexing in mind from the ground up it can handle thousands of concurrent connections and legitimate connections are given a fast track to the MTA since they have a good reputation.

In the case of Sendmail, it's a much different story. In the situation described above, the message from the zombie sender would be delivered in the same way as legitimate mail. The difference is that TrafficControl limits the data rate and Sendmail limits the connection rate which are two very different things. So what exactly does Sendmail throttling do? The following rate limiting features are explained:

ratecontrol - provides a per minute connection rate window that limits the number of connections, usually from a single server. If a connecting server exceeds this quota, sendmail then returns a 4xx response indicating it is temporarily unavailable. This is somewhat useful during a Denial of Service attack from a single machine but not useful against a distributed attack.

conncontrol - whereas ratecontrol limits the rate of connections, it's still possible for an attacker to gradually build up a pool of connections with Sendmail and eventually exhaust it's resources. The conncontrol feature therefore provides a limit on the total number of concurrent connections an individual host is allowed to maintain.

ConnectionRateThrottle - is similar to the ratecontrol feature but instead it provides a global per minute connection rate window that isn't specific to an individual host. This is more useful in the case of a distributed attack. However, it's still possible for the machines to continually build up connections over a long period of time and exhaust resourcess without hitting this quota.

greet_pause - as the name suggests is the addition of a brief pause in milliseconds before sending the banner greeting message. If a sender attempts to send additional commands without listening for the greeting the connection can be marked bad. This is easily circumvented by most spammers using sending software that actually listens for SMTP replies.

I hope this helps explain the difference between rate limiting connections versus slowing down an entire SMTP conversation to force a spammer to quit. If you'd like more information you can read the following description.

The Evolution of Spam

An interesting case study in the evolution of spam is the attack known as “Stock Spam” or “Pump and Dump”. Initially the format of choice was text or html as it provided a small message size reducing bandwidth requirements. However, this content was easily filtered so was not successful and resulted in a shift to image attachments. By the time content filtering companies developed a solution for image spam it had already evolved to use Pdf documents. Most recently the shift has been towards mp3 audio but even spam using Word and Excel documents have been seen.

The spammer is making a trade off between bandwidth and delivery success rate. The increase in messages size with advanced media is worth it since it's more likely to avoid content filters. In the future we can predict seeing any format that is easily viewable by applications on the average internet users PC. It's quite possible that we would see powerpoint spam or even video spam using a common format such as mpeg or avi. Similar to the audio clips where low sample rates were used to reduce file size, it's possible that low sampling and basic frame structure would be used to minimize bandwidth requirements. As spam is becoming increasingly targeted to individuals, will we see a day when a project manager receives Microsoft Project spam?

The Holiday Spam Surge

The Holidays are just around the corner and the associated seasonal spam surge is already underway. Traditionally we see a steep increase in spam levels from now until the end of Christmas. This can be attributed to consumers being easier targets due to an increase in their online shopping, an expectation of electronic greeting cards, a higher likelihood of impulse buying and difficulties with last minute gift ideas. All of these factors can be used by a spammer into convincing a user to open a spam e-mail or in some cases, tricking the user into providing financial information.

A common trick seen at this time of year of which e-mail users should be wary of is the "fake invoice". The natural reaction after receiving an invoice from a company for several hundred dollars is to follow the instructions to cancel the order, which often involves providing credit card information. In some cases, it can be even more subtle by simply providing a website which when visited will drop malware onto an unprotected computer.

Here is a sample of subject lines promoting gift ideas:

• We offer the most stylish Christmas presents ever!
• Christmas is an occasion for you to look more elegant!
• Perfect selection of stylish Christmas gifts in our store
• Fashionable but affordable Christmas gifts is not a myth!
• Visit our store and choose a wonderful Christmas gift!
• Affordable replicas would make perfect gift for Christmas!
• Feel the joy of giving beautiful things for Christmas!
• Give your loved ones amazing presents for Christmas!
• Elegant Christmas present is easy to find here!
• Visit this store to buy a Christmas gift!