Nerf's Up Dude! HostingCon 2008

Just back from HostingCon 2008 in Chicago. A really great conference full of interesting hosting industry professionals.

MailChannels were giving away Nerf Guns at the conference and they were so popular we did not have any left for ourselves!

We've uploaded some pictures from the conference to Flickr.



Looking forward to returning to the HostingCon in 2009!

University Spear Phishing

I've discussed the issue of Spear Phishing attacks on this blog before. Although I've never personally received a targeted phishing e-mail until this morning. As I'm a graduate of Dublin City University in Ireland, I have a lifetime e-mail account and the e-mail received is shown near the end of this post.

It claims to be from DCU Messaging Center and asks all students to verify their accounts, otherwise they will be deleted to create space for new accounts. I particularly love the use of the referenced Warning Code in the e-mail to make it seem legitimate. However, as Phil pointed out this actually helps find other related messages (1700+ of them) by searching for the very specific reference number.

A glance at the Received headers indicates the message originated from 41.205.163.40 and was received via Webmail (HTTP) rather than SMTP. The Phisher most likely used a compromised webmail account to send out the blast. As it was sent from a DCU webmail account to other DCU e-mail accounts it probably didn't pass through the Anti-Spam solution. The connection IP address is located in Nigeria and is listed on the Spamhaus SBL.

I alerted the DCU Computer Services Department to the phish and they were already aware of the issue. I e-mailed contacts in the Anti-Spam industry for a contact in the live.com security team to report this to. Fortunately, I was then able to contact a manager and request that the dropbox be terminated. This was important so that further replies to the e-mail address dcu.accountmanagement@live.com would not be received and it would also prevent the phisher from accessing details of current e-mails if they hadn't already retrieved them. An e-mail to the address now returns a 550 mailbox unavailable :)

I suggested that the University send out an e-mail alert to students so that anyone that responded could change their account passwords but afterwards noticed they do have an advisory. A student falling victim to the attack could have e-mails in their account that could be exploited for identity theft. For example, a credit card number could be available in the account. Hopefully the issue will be resolved quickly and no one will fall victim to this phishing attack.

Here's the message I received:

Received: from [41.205.163.40] by xxxxxxxx.dcu.ie with HTTP; Tue, 22 Jul 2008 04:56:30 +0100
Date: Mon, 21 Jul 2008 20:56:30 -0700
From: "DCU News Center"
Subject: Flag this message Email From Dcu Messaging Center/Verify Your Account
Reply-To: dcu.accountmanagement@live.com
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Dear Mail.Dcu.ie Account Owner,

This message is from DCU messaging center to all Mail.Dcu.ie account owners.
We are currently upgrading our data base and e-mail account center. We are
deleting all unused Mail.Dcu.ie account to create more space for new accounts.

To prevent your account from closing you will have to update it below so
that we will know that it's a present used account.

CONFIRM YOUR EMAIL IDENTITY BELOW

Email Username : .......... .....
EMAIL Password : ................

Kindly send the above details to our DCU messaging center via e-mail (dcu.accountmanagement@live.com)

Thank you for using DCU.IE!
Warning Code:VX2G99AAJ

Thanks,
DCU.IE Team
DCU.IE"
............................................................................
............................................................................
NOTE: This message is authorize by the Mail.Dcu.ie email account protector unit.
Notification message will be send back to you after verifying your account
before account could be reset. All right reserved.

Update: O2 Leaking Customer Photos

If you rely on secret URLs as a security mechanism, you should make sure your logs are not public.

On Thursday I posted a blog entry related to the security around O2's MMS Messaging service. My key point was that O2 were not authenticating the user and relied on URLs with hex strings to access MMS messages. Several people pointed out that URLs were adequate security given the hex strings were 64-bit keys so they couldn't be guessed. I did not disclose the full extent of the leak as it would have allowed access to non-indexed MMS messages and I wanted to give O2 a chance to fix this more serious problem first.

Note: We have made O2 aware of this more serious problem and because O2 has now taken its multimedia servers off-line, the vulnerability described in this post no longer exists.

Update: On Tuesday I received a response from O2:

Your details were forwarded to our project team who we believe have put a temporary fix in place at present. I'm unable to tell you when a permanent fix to this issue will be implemented. I would like to thank you for your feedback.

Here's how the attack works - Lets say a customer has a new iPhone 3G. The iPhone 3G doesn't support MMS messages, so if someone sends a MMS message to that customer they receive a notification to view it on O2's media server. The link to the media server is a private URL with a hex string, so when it's clicked on, an HTTP GET request is sent to the web server to retrieve the audio/image/video. This would appear to be secure, as someone would be more likely to win the lottery than guess the key. However, the private URL isn't so private when it's publicly available on the O2 web server.

The web server providing the MMS messages uses mod_jk with JBoss/Tomcat and the default security settings are minimal. There's an information disclosure vulnerability if the Status Page isn't locked down. The status page contains lots of system information such as the memory usage, data processed and discloses the URL's of the HTTP Requests to the server. As O2 failed to lock down the status page it was public and anyone could see which URL's were currently being handled in a web browser.

Here's a snapshot of the O2 Status Page I took where the HTTP GET requests were made available as well as the IP address of the client accessing the content. Once the URL is known the audio/image/video being viewed and the persons phone number are disclosed. Note: I've hidden most of the data but you can see where the GET requests would have been available.




The mediamessaging.o2.co.uk server is now back online and the status page is no longer viewable.

In the past year there have been 2 security issues with O2's infrastructure linked to URL's, although in these cases the URL flaw was much easier to exploit. Last February, the following Bluebook issue was reported:

Coding errors in Bluebook created a means for registered users to view other user's messages (and phone numbers) simply by changing the message ID number in URLs used to access messages on the site. In a statement, the mobile phone giant said that it has fixed the problem.

Last September, it was an issue with the Billing System:

Using the loophole in the site, it would have been possible to write a script to pull a list of mobile phone numbers assigned to particular firms, along with details of the calls made using those numbers over the last three months. In most cases, the name and department of the person making calls was also readily available.[...] Russell was able to access this information through a simple URL manipulation that allowed him to elevate his privileges to view information on the site.

O2 Leaking Customer Photos?

Mobile Network Operators have been providing SMS text messaging capabilities for years but it's only recently that MMS (Multimedia Messaging Service) enabled cell phones have become more popular. It allows an owner of the phone to take a photo and immediately send it to another MMS enabled cellphone. So what happens if a MMS enabled phone sends an e-mail to a non-MMS phone? Well, the mobile operators have thought of that and can host the images on their website and notify the user by text message or e-mail that a new photo is available to view.

You may assume that if you use this service to send a photo to a friend that your photo is protected and not broadcast for the entire world to see. Unfortunately, this may not be the case if there isn't proper authentication, such as username and password login, to the mobile network operators website that's hosting the images and here's an example of that case...

UPDATE - Full details of O2 MMS vulnerability revealed. Click here to read our latest blog post on this

Earlier today, we received an e-mail from O2 that was sent to an incorrect recipient. It's quite likely that an e-mail address was entered incorrectly by the person setting up the account. I was surprised that we were able to view the image without having to login to the website but figured a strict combination of a unique user id number and unique image id would be required making it incredibly difficult to guess. After all, it wouldn't be possible to access these images without receiving a misaddressed e-mail, right? Wrong!

I looked at the URL in the e-mail and found the only requirement was a 16 digit hex number. [Update: A few readers pointed out that a 64-bit key results in a HUGE number of possibilities to guess 10^19. However, as I can obtain the keys via another security hole no guessing is required - I'm not going to release that information yet as I'd like O2 to fix this]. As these web pages were wide open to the internet, not requiring any authentication a very small handful were indexed by Google. I was able to craft a Google search that results in some matches to show an example of how this is an insecure method of hosting:


http://www.google.com/search?hl=en&q=inurl:mms2legacy&start=20&sa=N&filter=0

Worse still, the majority of the images taken on cameras turns out to be children. Ironically, O2 has a website dedicated to "Protect Our Children", well a good first step would be to avoid leaking customer photos.

Update: Someone posted this story to the O2 Customer Forum website but the thread has mysteriously disappeared. Hmmm....I wonder why? The thread discussing this in the forum was here but now simply returns "The topic or post you requested does not exist" webpage. Google did manage to grab it....



Since then I've found the follow discussion of the issue on the O2 Customer Forum that hasn't yet been removed.....

Follow Up: Closed Relay - SMTP Auth Attack

On Monday, I posted a blog post related to an increase in SMTP Auth Attacks. Frank posted an interesting comment with a question which I thought was worth discussing:

Good posting. I haven't seen very strong support by MTAs to identify SMTP AUTH brute force attacks. Any comments on what vendors are doing, between Exchange (using AD on the backend), LDAP-based auth, and native system AUTH?

Of course the best way to mitigate exposure to a SMTP Auth Attack is to disable the feature. If it really is necessary to use it, it could be limited to specific IP addresses or subnets that are trusted such as a VPN, rather than allowing anyone in the world to authenticate. However, the comment obviously relates to a situation where SMTP Auth must be supported and the connection IP address of clients could come from anywhere.

In the case of an Exchange server mentioned above, it's not usually recommended to have the server in the DMZ from a security viewpoint. Instead, a SMTP proxy (which could be software/appliance/hosted) sitting in front of the MTA could be used to detect these attacks rather than relying on Exchange or the back end authentication mechanism to detect them.

Does Exchange actually have any features to combat an attack? To be perfectly honest I wasn't sure so I did a little digging. I was already aware of the tarpit feature in Exchange 2003 dicussed in this Knowledge Base article. As the tarpit feature is bypassed for authenticated sessions it's not clear if it would help prevent a SMTP Auth attack by tarpitting it due to failed authentication attempts. However, I did find a MS Exchange tutorial claiming that it did. I wanted to confirm this so I contacted our friend, Terry Zink, the product manager for Exchange Hosted Services to pass my query on to a relevant contact. He was kind enough to oblige and confirmed that Exchange 2007 does tarpit failed authentication attempts and was pretty sure that 2003 did likewise.

While I was writing this follow up to the original blog post, Frank also commented on the ability of other MTA's to prevent these attacks:

Incidentally, a vendor who has customized qmail (among other things) mentioned to me that they have rate-limiters per IP and username for just that aspect.

That's a typical way to mitigate this type of attack. Rather than allowing an attacker to hammer a mail server all day the authentication failures per ip or user can be used to detect it. It's quite similar to a SSH Brute Force attack and there's a unix solution, Fail2Ban, that can detect failed smtp authentications and create rules to temporarily ban the originating IP addresses.

If any of you are worried that you might be vulnerable to such an attack and are not even sure if this feature is enabled, you can check by telnet-ing directly to port 25, issuing a ehlo/helo and looking at the capabilities reported by the MTA to see if AUTH is listed. You could also check your outbound mail servers IP address against multiple blacklists using this tool multiple blacklists. It's also a good idea to monitor SMTP AUTH traffic at a perimeter firewall or SMTP Proxy to see any failures.

MailChannels | Traffic Control Blog

Dear Readers,

Today I'm happy to announce that MailChannels has launched the Traffic Control Blog. This new blog is all about Traffic Control, our email traffic shaping software, and will contain useful configuration hints, tips, and customer anecdotes to help you get the most out of Traffic Control.

If you are an email subscriber to the MailChannels Blog, you can also subscribe the Traffic Control blog by filling in your address in the box below:

Enter your email address to subscribe to the Traffic Control blog by email:

Upcoming Event: HostingCon 2008 - Chicago

The next opportunity to meet us will be at HostingCon 2008: July 28-30, Navy Pier Chicago!

Come by booth 427 for a cold energy drink and don't miss CEO Ken Simpson share a panel discussion on The Hidden Costs of Spam and How to Control Them:

Date: July 28, 2008
Time: 9:00 AM
Session #301

Interested in attending? Use the registration code (158-10e08b4) to receive discounted pricing:

$60 Discount on Full Conference w/ Lunch Passes
$40 Discount on Full Conference without Lunch Passes
$30 Discount on Single Day Conference Discount Codes
$20 Discount on Exhibit Hall Only

Registration details here.

Closed Relay - SMTP Auth Attack

A few days ago, I received a phishing e-mail to a personal e-mail account. Out of curiosity, I happened to check the received headers and noticed it had been relayed via an Exchange server. A quick check of the company website of the Exchange server operator, indicated it was very likely a legitimate mail server being abused as a relay. My first thought was that the Exchange server had been mis-configured as an open relay but with a little investigation I found it was actually a closed relay, victim to an SMTP Auth attack.

An Open Relay allows anyone to connect to the mailserver and send e-mail to anyone from it. This was a typical default configuration at the time but due to their abuse by spammers this quickly changed. System administrators had to close the relays, so that mail would only be accepted for local domains or else end up having their outbound mailserver listed on multiple block lists. At one time, the majority of spam originated from open relays but due to aggressive blocking this dropped to a small percentage over time as the use of botnets took over.

So what is a closed relay? To allow remote users to authenticate to the outbound mailserver, SMTP-AUTH can be used. Unfortunately, a spammer can perform a brute force attack to guess the username and password to an account on the mailserver. In the case I mentioned above, they were able to guess one of the common usernames and break a weak password. Once the spammer was able to authenticate with the mailserver, they were then free to use it as a relay even though it wasn't mis-configured as an open relay.

I should point out that this type of attack has been happening for years. However, it seems to be increasing in popularity in recent months. I contacted the company responsible for the exchange server and explained that an account had been compromised and the consequences. They had already been listed on one blocklist, which even provided samples of phishing e-mails originating from their server. Fortunately, they were quickly able to secure their server and be removed from the blocklist before it damaged their business due to blocked e-mails. So if your mailserver is using SMTP Auth consider whether it's actually needed and if so, if it's sufficiently protected against SMTP Auth attacks.

Spam in the Cloud

Last year I wrote a blog post titled Spammers in Space, describing how webmail spam from Africa often uses satellite internet connectivity. Well, now it seems that Spammers are in the clouds!



Cloud computing is becoming increasingly popular as it allows a business to quickly and cost-effectively deploy additional servers based on demand. Third party providers own huge server farms and share the hardware among users. For new Web 2.0 startups it's an ideal way to effectively rent a server on an hourly basis rather than paying the outright hardware costs. It is an excellent service and we use it to bring up a huge number of machines for short durations of load testing.

However, the model is open to abuse as a new IP address, owned by the cloud computing provider, is typically allocated with a new instance of a server is created. It's been speculated for quite a while that this could be used to send spam but now it's actually happening. The Washington Post covered the use of cloud Services to send malware. Our Technical Advisor, Justin Mason recently blogged about the issue and the story appeared on Slashdot with the comment:

"EC2 space is now actively blocked by Outblaze, and has been listed by Spamhaus in their PBL list [...] However as Seth Breidbart noted in the comments, 'note that Amazon will terminate the instance. That means that the spammer just creates another instance, which gets a new IP address, and continues spamming.' True enough -- as described, instance termination simply isn't good enough."

So what does this mean? Given that the current Anti-Spam Policy enforcement in cloud services appears to revolve around terminating the instance rather than the account it's very open to spam abuse. The Anti-Spam community need to protect their customers so are forced to list the IP space on blocklists. For example, Spamhaus has marked the EC2 address space in it's PBL - Policy Blocklist which is widely used to block e-mail from dynamic IP space. Any Web 2.0 companies using cloud computing will need to realize that there's a high probability that e-mails generated directly from the cloud to the recipients MTA could be rejected as spam.