How not to write a mass email to your customers.
Customers are beginning to lose trust in email. With good reason: it is easy to spoof and it has been a leading threat vector for phishing and malware attacks. This means that you need to be extra careful when sending mass-email to your customers.
Earlier this month I received a message that claimed to be from Amtrak [amtrak@amtrak.bfi0.com]. It said:
Dear Customer,
Changes Coming to Your Amtrak.com Login
In an effort to streamline the login process and communicate more effectively with our customers, we will be changing the way you access your Amtrak.com account in a few weeks. Prior to this update, we ask that you log in to verify the accuracy of the information in your account.
• Go to Amtrak.com Now and Update Your Profile
This change will not affect how Amtrak Guest Rewards members log into amtrakguestrewards.com. [The message continued... Cut for brevity.]
I cannot complain about the text of the message. Unfortunately, the words "Go to Amtrak.com Now and Update Your Profile" were a hyperlink that led to a third-party website, amtrak.bfi0.com. The same was the case with a few other links embedded at the bottom of the message.
Links to websites not associated with the company's recognizable domain are a tell-tale sign of a phishing message. It seems that the message was authentic after all, but how were the customers to know? A phishing message targeting Amtrak customers would look exactly like this, though it would point to some other cryptically-named domain instead of amtrak.bfi0.com.
Companies often use mass-mailing services to send out such communications and to collect click-through statistics. This mail be appropriate for marketing-type messages, but is not wise for sensitive communications that deal with logon procedures or credentials.
If you need to send a sensitive mass email to your customers, consider:
- Do not include any links in the message at all. Instead, ask the recipient to visit your company's website using the address they know (www.companyname.com) or have bookmarked in the past.
- If you need to include links, make sure they are to websites hosted under your company's recognizable domain, such as abc.companyname.com. For bonus points, use an HTTPS link, instead of HTTP, with a valid SSL certificate to help the customers validate your site's authenticity.
- Warn the customers in advance that they will receive an email from you via a status update on your website or in the regular reports you may already deliver to your customers. Explain how the customers can confirm the authenticity of your message.
Do you have any suggestions for communicating with customers via email? Let us know.
Update: David Wharton wrote to share his experiences handling phishing campaigns against his bank's customers. Sometimes he sees "phishing emails that contain valid (non-phish) links and do not point to a phish site. The links to login actually go to our login page. My only thought as to the reason they would do that is to add to overall customer confusion." Indeed, adding to customer confusion could be a reason for seeing valid URLs in phishing messages. Alternatively, we may be seeing these messages in the early testing phase. Finally (as was pointed out by another ISC handler), the senders of these messages may be targeting victims whose DNS records may have been tampered with, so when they access www.companyname.com, they will be pointed to an IP address of the attacker's server.
Update 2: Ned Slider mentioned that another reason for phishing emails containing links to legitimate sites could be that "the phish victim may already be infected with keylogging malware designed to capture authentication on legitimate websites." (Looks like T. K. had the same idea, and posted it in the comments to this diary.)
Update 3: John Silvestri pointed out that Steven Bellovin described his perspective on the same Amtrak email earlier this month in his blog. Thanks for the pointer, John!
Update 4: Ray Ellington recommended that senders use DomainKeys, "an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity" (according to Wikipedia). Ray mentioned that "most people probably don't even notice since you must click 'Details' in most web based email browsers to see that it has been signed. But for those who understand what digital signing of email is they can click" and confirm the message's origin.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
If site not apeared - Click Here
We received messages from two ISC readers, who reported an increase in spam messages that include a link to sub-sites of blogspot.com. (Thanks, Matthew O. and J. T.) The fake blogs, set up on blogspot.com for this purpose, briefly display the phrase "If site not apeared - Click Here ." before redirecting the visitor to another site via a meta refresh tag, such as:
<meta content='0;URL=http://gentsoftnowu.com' http-equiv='refresh'/>
(Watch out, that gentsofnowu.com URL is not friendly!)
The spam messages we've seen advertise Microsoft Office Enterprise 2007 software, and use subject lines such as "Microsoft Office ready to download" and "Microsoft Office 2007 OEM version". The body of the email currently looks like this:
Microsoft Office Enterprise 2007 includes:
• Access 2007
• Communicator 2007
• Excel 2007
• Groove 2007
• InfoPath 2007
• OneNote 2007
• Outlook 2007
• PowerPoint 2007
• Publisher 2007
• Word 2007
http://teriwatlerop.blogspot.com
(Watch out, another maliciously-predisposed URL there!)
A Google search for "If site not apeared - Click Here" produced one unfriendly-looking website that resembles the ones hosted on blogspot.com, and a blog posting that describes an incident that might be related to this campaign and vents about Google. A Yahoo search for this phrase leads to two reports on malicious sites hosted on blogspot.com (1, 2). An MSN search produces another report. (Are you surprised I used more than one search engine? Me too.)
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
Adobe AIR is out. Let's talk about security.
Today marks the official release of Adobe AIR, a platform for developing desktop applications using web-based technologies. Let's see what this tool offers and what security implications it carries.
Adobe AIR (once known as Adobe Apollo) is a run-time environment that bundles several web-enabling technologies and makes them available on the desktop. According to Adobe's Mike Chambers, Adobe AIR "leverages a number of open source technologies," including:
- Tamarin - implements JavaScript/ECMAScript, used in Firefox, Flash
- SQLite - lightweight database engine
- WebKit - renders HTML, used by Konqueror browser in KDE and Safari
Adobe AIR allows developers who know how to write traditional web-based applications to use their skills (HTML, AJAX, Flash, etc.) to write local desktop applications. Applications built using Adobe AIR include AOL Top 100 Videos player, eBay Desktop, and NASDAQ Market Replay.
ISC reader Richard Gurley emailed us a question regarding security concerns associated with the this powerful development platform. Two categories of threat vectors come to mind:
- A malicious Adobe AIR application may act as a trojan and do "bad things" to the victim's local system.
- A web-style vulnerability (XSS, etc.) in an Adobe AIR application may allow an attacker to target the application's data or the victim's local system.
Desktop-Specific Threats of Adobe AIR Applications
The set of first threat vectors is similar across desktop applications that run locally. Adobe implemented sandboxing to limit some actions a local Adobe AIR application. Adobe's documentation makes it clear that the sandboxes are not meant to mimic the rigorous restrictions of a web browser's sandbox. Adobe AIR FAQ points out that "applications deployed on Adobe AIR have powerful desktop capabilities and access to local data."
Adobe AIR applications need to be digitally signed, to assist the end-user in determining whether to trust the application's author. However, the certificates can be self-signed, and many users will ignore the trust warnings and run even those applications that come from untrusted sources. This is not a new issue, and it is not unique to Adobe AIR.
Ron Schmelzer, an analyst at ZapThink, expressed his concerns with the ability of existing anti-virus tools to protect against rogue Adobe AIR applications in an October 2, 2007, InfoWorld article:
" 'The current generation of spyware, virus, and malware [detection] products have no visibility into running AIR programs,' Schmelzer wrote in an e-mail. 'As such, there is a high possibility for malicious AIR applications -- which are no longer security-restricted to the browser sandbox and are free to manipulate local machines -- to spread into the wild.' "
I am more optimistic about the ability of existing anti-virus suites to detect improper actions of an Adobe AIR application through behavioral techniques that observe any local programs. Such techniques involve checking for suspicious registry, file system, and network actions that a malicious application would exhibit regardless of the framework within it operates. However, since I have not experimented with Adobe AIR applications, this is purely a hypothetical assessment. (Perhaps those more familiar with inner-workings of anti-virus tools or with Adobe AIR applications would like to comment?)
Web-Specific Threats of Adobe AIR Applications
The other, and perhaps more significant set of threats to consider is tied to those of any web applications. Vulnerabilities in a web application could allow an attacker to launch attacks based on Cross-Site Scripting (XSS), SQL injection, local link injection, and other techniques associated with traditional web applications.
The most interesting security repercussion of a platform such as Adobe AIR is that it merges traditional web application techniques with the more-permissive security models of local applications. Consider a hypothetical example where an Adobe AIR application allows the user to open and execute a local file. An XSS-style vulnerability in an application could allow a remote attacker to inject a malicious JavaScript into the application that would attempt to execute a local program of the attacker's choice. This is more difficult to execute when the script runs within the confines of a web browser, than if the script runs within a more permissive sandbox of Adobe AIR.
Adobe's Lucas Adamski wrote an excellent article describing the Adobe AIR security model. In his write-up, Lucas describes the two sandboxes implemented by Adobe AIR and outlines the security risks that the developers of Adobe AIR applications need to consider. He also points to the security documentation Adobe wrote to assist developers in addressing some of these challenges. Lucas highlights the need for developers to follow Adobe's security recommendations to create resilient applications:
" However, the privileges inherent in a full desktop application mean the developer can sometimes find ways around these restrictions. The reality is that doing so will almost certainly introduce a large amount of security risk into the application and for the end users of the application. Thus Adobe strongly recommends that developers stay within the restrictions placed by the AIR security model, and carefully consider the cost of implementing rigorous security mitigations for bypassing them. In most cases the development cost of these mitigations will significantly exceed the cost of finding an alternative solution that stays within the bounds of the security model. "
Undoubtedly, many developers will be unaware of Adobe AIR security best practices or will knowingly take shortcuts that expose end-users to attacks. Will our destkop lock-down practices and anti-virus tools compensate for such conditions? I hope the answer is "yes," but I suppose only time will tell.
What are your thoughts on security implications of the Adobe AIR platform? Please let us know.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
Comments