My first thought was that Ticketmaster had a dodgy redirect on their site, until I looked at the email and saw that it was actually sent from Ticketmaster’s network.  I have broken my current findings down below.

Update 1 day later: See the comments at the end of this post. I have also received the same email from Ticketmaster confirming that they had a security breach. However the links are still active, which shows they possibly don’t have a proper handle on this yet.

Update 2 days later: See my followup post.

The spam email

The first part of the email body looks like this:

INTRODUCING UPGRADED ADOBE ACROBAT READER 2012
Since the Holidays are in full swing and the New Year is approaching, we've decided to unveil our latest Adobe PDF Reader/Writer 2012 Version

http://www.2012-acrobat-adobe-download.com

The link actually points to a rather long URL:

http://smr.mm.ticketmaster.com/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTE0MTQzNjMmbWVzc2FnZWlkPTE0NDU0MjMmZGF0YWJhc2VpZD1EQVRBQkFTRUlEJnNlcmlhbD0xNjgxNzIzMyZlbWFpbGlkPWRhdmlkQGVkZWNhLm5ldCZ1c2VyaWQ9NTM3NzYyMzE3JmZsPSZleHRyYT1NdWx0aXZhcmlhdGVJZD0mJiZodHRwOi8vd3d3LjIwMTItYWNyb2JhdC1hZG9iZS1kb3dubG9hZC5jb20v

The important headers (which can be faked, it is important to remember) were:

Received: from dspam by mx.lionserver.co.uk with dspam-checkedid 1RwEuO-0004HV-Re
for MYEMAIL; Sat, 11 Feb 2012 15:30:40 +0000
Received: from sms1-els203-83.mm.ticketmaster.com ([209.104.36.83])
by mx.lionserver.co.uk with esmtpid 1RwEuI-0004HJ-4v
for MYEMAIL; Sat, 11 Feb 2012 15:30:40 +0000
Received: from sms2.mm.els203.clisys.tmcs ([10.75.20.210]) by sms1-els203-83.mm.ticketmaster.com (-); Sat, 11 Feb 2012 07:29:57 -0800
X-VirtualServer: Default, sms1-els203-83.mm.ticketmaster.com, 10.75.20.213
X-VirtualServerGroup: Default
X-MailingID: 16817233::1414363::DATABASEID::1445423::537762317::202579
X-SMHeaderMap: mid="X-MailingID"
X-Destination-ID: MYEMAIL
X-SMFBL: ZGF2aWRAZWRlY2EubmV0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
boundary="----=_NextPart_22E_57A8_7C013F27.75C101A9"
MIME-Version: 1.0
Message-ID: <16817233.202579@TICKETWEB.CO.UK>

So there appears to be a received header indicating this came straight from Ticketmaster’s network, and a few Ticketmaster specific headers. The Ticketmaster header X-SMFBL contains my email address, base64 encoded.

Mail origins

The received headers suggest this email came from 209.104.36.83. This could have been added by a spammer, so let’s check the server logs and see where it really came from:

2012-02-11 15:30:40 [16449] 1RwEuI-0004HJ-4v <= return_smverp_.16817233.1414363.DATABASEID.1445423.537762317.202579._smverp_.david=edeca.net@ab.mm.ticketmaster.com H=sms1-els203-83.mm.ticketmaster.com [209.104.36.83] P=esmtp S=6908 id=16817233.202579@TICKETWEB.CO.UK T="Action Required : Update Your PDF Application"

The mail server confirms that it did come from 209.104.36.83. That IP address is sms1-els203-83.mm.ticketmaster.com, the netblock is registered to “Ticketmaster Online – CitySearch, Inc.”.

The embedded URL

The URL above contains a long Base64 encoded section which decodes to:

eas=1&mailingid=1414363&messageid=1445423&databaseid=DATABASEID&serial=16817233&emailid=MYEMAIL&userid=537762317&fl=&extra=MultivariateId=&&&http://www.2012-acrobat-adobe-download.com/

Much of this again seems to be Ticketmaster specific. The messageid matches with the information in the X-MailingID header above. At the end is the obvious redirect to the fake website above.

The fake website

The fake website is nothing special but does use Adobe’s trademarked logos and styles heavily. The disclaimer at the bottom probably wont get them out of this. The website only exists to point the user to an affiliate link for some PDF related software, which has nothing to do with Adobe itself. A screenshot of the website is below (click for bigger):

Conclusion

Nothing conclusively shows that Ticketmaster have been hacked. It could be an affiliate of theirs, or a customer who has permission to send emails using the Ticketmaster service. What is clear is that it definitely came from Ticketmaster and uses their service.

Four hours after this was first reported to Ticketmaster on Twitter the link still works and some spammers somewhere are still collecting the click-through cash.

Whatever transpires, I’ll be unsubscribing.

This list of rules doesn’t fit very well with my password scheme, primarily because what I computed in my head fails the test for uppercase characters.

Using the phrase “this is an unbelievably long password that would take a very long time to crack” fails this rule too, as well as the tests for a number and punctuation. I’m not suggesting that this is a good password, but it’s certainly better than “aA1!bcde” which passes all the rules. These 8 characters are trivial to brute force on any modern machine even if the underlying software uses a salted hash.

The offending software appears to be Jive, who perhaps need to set some more sensible defaults on their login system.

After a week I have seen a number of accesses to this site using IPv6. I also added an AAAA record for my mail exchanger at the same time, but so far haven’t seen any legitimate messages delivered. SSH login attempts have also been absent, which is good as apparently denyhosts doesn’t support IPv6 just yet.

It is worth considering security too. By default, ip6tables is permissive in ALLOW mode. This has security implications for link-local addresses if the attacker is on the same network segment, but definitely needs thought if you add routable IPv6 addresses. I copied my existing set of iptables rules and modified them where necessary, only allowing the essential services.

Be the first to comment from an IPv6 address!

On a sensible Debian or Ubuntu install, getting denyhosts is as simple as running:

denyhosts should work as soon as it is installed. However, a few options can be tweaked to make it work nicely. The configuration file is at /etc/denyhosts.conf.

Firstly, set a proper administration email by changing ADMIN_EMAIL. The option RESET_ON_SUCCESS might also be important to you, by setting it to yes the failure count for an IP address will be reset if there is a successful login. If you want the blocks to expire (which is more important if you use synchronisation) then you should tweak PURGE_DENY to a sensible value, for example 1 week.

Synchronisation is one nice feature of denyhosts that means that information on IPs that attempt SSH bruteforcing can be shared between servers. Information about synchronisation can be read in the FAQ but enabling it is as simple as uncommenting the SYNC_SERVER line.  By default, your server will share information on bruteforcers and receive it from other administrators who run denyhosts.

You can check how denyhosts is working by watching the logfile at /var/log/denyhosts.  You can see newly added blocks logged as a line like the below:

new denied hosts: ['202.107.228.xxx']

Of course, you don’t need this as you’ve already disabled SSH password logins and your firewall disables access to port 22 from anywhere except a specially crafted list of IPs.  But for 5 minutes work, it provides some peace of mind.