Ticketweb (a UK arm of Ticketmaster) have confirmed that someone was able to send emails to subscribers fraudulently. Their initial response was covered on the Naked Security blog.

A second email was sent out this evening:

One part which stands out says:

We sincerely regret any concern that may have been caused by this incident and we can assure you we took immediate action to close the unauthorised access as soon as it was identified.

This isn’t quite true, Ticketmaster’s own webserver still issues redirects to people who click on the original link. (Note: I don’t recommend you do this unless you are aware of the potential consequences!)

$ curl -D -  "http://smr.mm.ticketmaster.com/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTE0MTQzNjMmbWVzc2FnZWlkPTE0NDU0MjMmZGF0YWJhc2VpZD1EQVRBQkFTRUlEJnNlcmlhbD0xNjgxNzIzMyZlbWFpbGlkPWRhdmlkQGVkZWNhLm5ldCZ1c2VyaWQ9NTM3NzYyMzE3JmZsPSZleHRyYT1NdWx0aXZhcmlhdGVJZD0mJiZodHRwOi8vd3d3LjIwMTItYWNyb2JhdC1hZG9iZS1kb3dubG9hZC5jb20v"
HTTP/1.1 302 Found
Date: Mon, 13 Feb 2012 23:46:55 GMT
Server: Apache/2.2.3 (Unix)
set-cookie: CAMEFROM=NTFMM1414363_1445423[click; domain=.ticketmaster.com; path=/;
Location: http://www.2012-acrobat-adobe-download.com/
Content-Length: 0
Connection: close
Content-Type: text/html

This 302 redirect instructs your browser to go to the URL in the Location header, which is still set to www.2012-acrobat-adobe-download.com.

The domain name was registered through Regtime Ltd., who pop up on sites including:

• The Zeus Tracker
• A “Spotting the bad guys” page from 2009
• The SpyEye Tracker
• Numerous other spam trackers

There is still a valid A record giving the IP address 121.11.80.161 but there is currently no HTTP service running on port 80. This suggests that even though the site is currently down the bad guys behind it probably still have access to their own DNS.

Other articles

By now this has been covered extensively including at ZDNet (Hackers compromise Ticketweb email system) and The Register (“TicketWeb coughs to email database hack”).

Final thoughts

It is good that Ticketweb have taken this seriously and have issued some sensible advice. This is a responsible way of handling any sort of security incident.

However it would be great to see the original links killed so that there is no possible chance of anybody else falling foul to the emails from this point onwards.

This afternoon I received an email with the spammy subject “Action Required : Update Your PDF Application”.  I almost ignored it until I noticed that the link inside pointed to a domain owned by Ticketmaster. As I have shopped with Ticketmaster before, perhaps this isn’t so surprising.

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.

Today I forgot the password for a site I use only occasionally. This is rare, as I have a number of password schemes that I use to create a password unique to each site. After clicking the reset password link, I am confronted with the “password strength checker” below:

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.

So I thought I was being a good internet citizen when I received the following email a week ago:

Dear User;

Please update to our new server click here to begin

http://glacierdesign.ca/phpform/forms/form1.html

Thanks and have a wonderful day.

Webmaster

The site looked like this:

For a while I was confused, after all I run my own email. Did I really need to remind myself of my password? And what had happened to my unlimited quota?

Then I figured it was obviously a phishing email, so I turned to “do no evil” Google to report it. If the site was included on their block list then users of popular browsers would automatically receive a warning if they tried to go to it.

I tried using the Google report phishing form, even filling in the headers and body of the email in the comments box. Unfortunately, a week later the site is still up and presumably conning less savvy users.

Surprised by Google I’ve just tried the badwarebusters.org report feature, let’s hope it works slightly more efficiently!

Occasionally I see packet captures which have been saved as Raw IP, which can really mess up many of the tools developed to deal with pcap. Anything based on libnids, including the Perl module I maintain, cannot deal with it and will produce no (or bizarre) results. Wireshark displays these captures just fine, with “Raw packet data – no link information available” just above the IP layer.

There are many situations where packet capture will lack the ethernet header for a good reason, but if you simply want to run it through other tools that deal only with IP and above then adding a fake header is a viable choice.

Fortunately, adding a “fake” ethernet header to these pcap files using tcprewrite (part of the tcpreplay suite) is simple:

Overriding the output data layer type is essential, as is providing the ethernet MAC addresses of the two endpoints. That’s all there is to it.

tcprewrite is available as part of the Debian package tcpreplay.

Whilst the Sharp Architecture maintainers have little interest in Razor (see here), I have been using it recently and like the syntax.

Swapping out a default project to use Razor instead of (or in addition to) the default engine isn’t too difficult.

Enabling the view engine

In Global.asax, find the few lines below in Application_Start():

We need to register Razor here, by adding the line below:

If you do not plan on using the default view engine then you can comment the existing line and remove all the .aspx files from the Views directory.

Configuring the default layout

Create an empty file called _ViewStart.cshtml in the root of your Views folder:

This code runs before any other view code in this directory or below and sets the default layout so you don’t have to set it manually in every view (see the MVC3 release notes for more information).

Create a basic template

Lastly we need the layout which was referenced above, created as Views/Shared/_Layout.cshtml. You could copy and paste this from a new MVC Razor application, which is what I did to end up with the template below:

Conclusion

This is all that should be necessary to enable Razor and start to return basic views from your controllers. From here on you can create views just like in the MVC3 tutorials.

This blog can now be reached over IPv6 (or ipv6.edeca.net), which is surely the final nail in the coffin of IPv4 across the internet.
Read the rest of this entry »

The other day I pushed a new version of Net::LibNIDS to CPAN. It interfaces with the C library libnids in order to provide TCP stream reassembly and returns the data to your Perl callback.
Read the rest of this entry »

Anybody who has used command-line systems for a serious amount of time will love grep. But today I stumbled across ack, which (for many things) is better than grep and a whole lot nicer to use.

The best bit? It’s pure Perl, therefore also uses real Perl regular expressions. Yes, there might be grep --perl-regexp, but nobody bothers compiling that in. Plus ack has some other neat features.

See more at the ack website.

It is sometimes useful to limit the running time of a process, either to stop it from using up all resources or to make sure nightly cron jobs don’t continue into working hours.

I needed this for rsync, to let a remote backup server slowly catch up if large amounts of data were added to the live server during the day. A useful post on the rsync mailing list discusses an rsync patch but also the timeout command.

After installing (the Debian package is simply timeout) it is as easy as running with the number of seconds to run for:

It is also possible to specify the signal which will be sent to a program, which is useful if you do not want to simply send SIGKILL. I used SIGHUP in the hope that rsync would have a chance to exit gracefully:

A full list of signals and their numeric values can be found in man 1 kill.

A wrapper script is also available from Johannes Buchner.