New York Times Gets It Wrong: Phishing Does Hurt Us All

Monday, November 30th, 2009

The teaser appearing in the bottom corner of the New York Times print edition’s Sunday Business section looked promising: Phish foil. Digital Domain. The article’s title, Don’t Take This Bait (But You’re Safe If You Do), suggested there would be more coverage of phishing, a generic name for attempts by online criminals to gain internet users’ login credentials to online banking services by presenting them with fake login pages. Unfortunately, while Stross’ article did indeed discuss phishing and offered some tools internet users can use to keep their bank accounts safe online, the article’s main message completely misses the mark.

The article begins relaying a close encounter that FBI Director Robert S. Mueller III had with a phishing attack. Although Mueller reportedly did not fall victim to the attack, Mueller emphasizes the lengths criminals go to gain access to one’s bank funds through email-based phishing attacks. Unfortunately, the crux of the article boils down to this:

I’m not convinced, however, that online banking carries the high risk that Mr. Mueller implies. I know that as ordinary computer users, we are offered unlimited bait from phishers. But I’m not particularly worried: I’m not on the hook for losses from fraud — my bank is.

The article concludes  emphasizing that banking customers need not worry about falling victim to phishing attacks because virtually all financial institutions offer full remuneration in cases where unauthorized individuals access and remove funds from an online account.

At a very narrow and superficial level this premise is true and provides some comfort to victims of an attack. However, the reality of this situation is that every time a phishing attack succeeds, it has very negative side effects for all who use online banking. Yes, the bank whose user fell prey to the phishing attack is on the hook for the stolen funds, but we have learned all too well in the past eighteen months that even the largest financial institutions do not have infinite resources. Banks do not simply create money to compensate the victims of phishing attacks – those reimbursements come from insurance policies or income the bank generates from fees levied on its customers. When the banks’ insurance premiums increase or overall costs rise – as they do when their customers get phished – the increases are passed onto consumers.

Further, many victims of successful phishing attacks who have had their money stolen probably would not agree that there is “zero liability” to online banking. The time lost while reporting the attack to their banking institutions is time without access to funds they count on to be there. While banks make an effort to minimize the time phishing victims go without their funds, the process is not immediate and the customers may be left without money needed for critical expenses like food and housing.

The New York Times is to be commended for raising general awareness about the dangers of phishing attacks . But minimizing the impact of phishing is a dangerous message that only helps online criminals.

A Dangerous Blend of Phishing Methods Continues to Plague Organizations

Monday, November 23rd, 2009

This past October, Cyveillance reported that cyber criminals were exploiting outward facing Microsoft Exchange Mail Servers to customize/personalize emails in order to spoof the address of internal email addresses. Once the email addresses were spoofed, the bogus messages were sent to addresses of the organizations’ personnel. The messages asked the recipients to click on a link in order to change the security settings. Once clicked, the users were routed to a fake Web site and if a user clicked on the link to the executable file on the site, then malware was downloaded to his or her computer. More info at: http://www.cyveillanceblog.com/general-cyberintel/a-dangerous-blend-of-phishing-methods

Unfortunately, cyber criminals are encountering success with this attack method because similar attacks continue today. Over the weekend, both Cyveillance and its customers received multiple emails similar to the one below:

 continued

Like in the attack illustrated in our October posting, the email requests the user to click on a link to false Web page. The Web page instructs the user to download a file that contained malware. The malware in the attack above was downloaded and analyzed by the Cyveillance Security Lab. Once installed, the malware made several communication attempts to URLs at 193.104.27.42/livs/rec.php and 193.104.27.42/lcc/ip2.gif. The first URL received encrypted data from the infected host making it difficult for security researchers to analyze while the 2nd URL was a Zeus Binary used to capture banking credentials.

The lab also observed additional attempted TCP connections to 66.199.251.242 on hundreds of different port destinations. It appears that the infected host was scanning the IP address for other services that may be running. The scan was of low intensity to avoid IDS detection. In summary, it appears that server located at 193.104.27.42 is the command and control server, which instructed this infected host to port scan 66.199.251.242 for known services and report back with the collected data; a dangerous, but effective combination of attack methods.

IT departments should continue to monitor for suspicious activity related to the attack described above as well as educate their users on the latest threats that plague the Internet. Users can minimize the potential for falling victim to email and Web-based attacks by never clicking on links within emails and only accessing their online applications through known Web sites and pages.

Google Search Results Significantly Poisoned

Monday, November 16th, 2009

Hundreds of Thousands of Links Leading to Malware Found in Google Results

Cyveillance has discovered a complex attack vector that uses Google search results to distribute malicious software (malware) to unsuspecting Internet users. Using this attack vector, users click on links within Google search results and are routed to sites that attempt to download malware to their computers. The attack method also relies on inattentive webmasters who do not update the software on their sites and often unknowingly provide the material that appears in the search results.

The screenshots below display examples of blogs with posts that are simply images and contain no text or stories:

secondnumber2

The common string albums/bsblog/category is found in the URLs for all these blogs. By simply using the Google search parameter allinurl, along, you can see how many other sites contain the same string.

albums-bsblog-category
More than 260,000 poisoned Google results. If you carry out the same Google search, DO NOT click on the results.

As can be seen in the image above, more than 260,000 URLs are presented in Google’s search index leading to blogs similar to the ones illustrated in our example. Beware: if you were to visit one of the above blogs after clicking on the URLs in Google search results, then you would be taken to two different websites. The second site would attempt to install fake anti-virus software on your computer. (For safety purposes, we are not directly linking to infected search results, but if you enter the query shown in the image, you can recreate the above results.)

Readers can simply copy and paste the destination URL into your browser to direct it to the desired website, you would be taken to the boring but otherwise harmless blog posting like those pictured earlier in this discussion. The attack only happens when the compromised blog site determines that you arrived by way of Google by checking the HTTP referrer.

An earlier search similar to the one above produced 104,000 infected URLs:

bmsblog-category
Another 104,000 results that will lead to malware. Again, if you carry out the same Google search, DO NOT click on the results.

As you can see, only a small portion of sites in the search results carry a warning provided by Google. The reason for the small number of warnings is likely because the actual attacks do not take place on the website URLs in the search results, but on the sites you’re redirected to thereby decreasing the chances that Google will designate the destination sites as harmful.

Digging Deeper

On all the infected sites found there is rogue blog publishing software installed, sometimes in the popular online photo gallery software Coppermine. (The most recent version of Coppermine we observed being used in this attack was 1.4.24, and Coppermine is now on release 1.4.25.) These rogue blogs automatically and regularly publish new posts that are titled with esoteric terms like “las vegas rental no credit check”, “real world melinda and danny”, or “uninvited song lyrics alanis morrissette morissette”. These posts are intentionally not titled just with simple terms that are very popular like “Britney Spears”, “Obama” or “Paris Hilton” to avoid having to compete in search rankings with the millions of pages which already exist for these topics. Instead, the authors of this exploit take advantage of the long-tail of search where rare combinations of search terms in aggregate make up a very large portion of the queries made by web surfers in search engines. In fact, a surprising amount of internet searches contain four and five words, and the authors of this attack appear to have titled their blogs’ titles with this in mind to be exposed to as many potential victims as possible.

No words are to be found in these blog posts. The content of each post consists solely of images that are found among images.google.com results of queries for the same terms found in the post’s title. Each of the images are then presented inside the new blog post and contain alt and title tags which also match the post’s title in an attempt to maximize the relevancy in Google’s eyes for any query matching those terms. For example, if one of these blog postings was titled “common and kanye west”, the blog posting would simply contain four or five of the images shown in the results of a Google image search for “common and kanye west”, and each of these images would in turn be given alt and title tags that read “common and kanye west”.

images-on-images images-on-site

The repetition of the same terms in the post title and image tags is a clumsy but straightforward mechanism of suggesting to Google that the page contains highly relevant information about those topics, hoping that Google will then present these pages to searchers. When the searchers click on these links in Google search results, the blog will redirect that visitor to the fake anti-virus installation site.

The Attack

infected
Image of an attack site in progress.

The fake anti-virus site displays what appears to be the results of a computer scan, warning the user that “31 Malware programms was found!” (sic). The fake notifications display illegitimate Windows anti-virus warnings regardless of the user visiting the site on a Macintosh, as happened in the pictured example. Interestingly however, it did correctly dynamically insert this researcher’s computer’s IP address into the image (which has now been blurred out). Clicking on anything in the fake infection findings, including the blue framed popup, will result in a file named Inst_58s6.exe being downloaded to the user’s computer.

Where the Wild Things Are

The path from the infected websites to the fake anti-virus software drop sites is swift and likely not noticed by the user. A user will click on one of the innocent-looking Google search results and is transported to a “middle man” domain like ionisationtools.cn or moored2009.cn. The server at these domains will then redirect the web surfer to a final destination where the fake anti-virus is pushed on the user, as described above.

The middlemen domains like ionisationtools.cn or moored2009.cn are “live” for just a day or two and quickly go offline. Their DNS records briefly point to the free DNS service provider EveryDNS.net.

The actual fake anti-virus drop sites are found on domains such as:

  • premium-protection6.com
  • file-antivirus3.com
  • checkalldata.com
  • foryoumalwarecheck4.com
  • antispy-scan1.com

All these domains observed by Cyveillance were registered with Chinese registrar TodayNIC.com and like the middlemen sites above, these domains are registered one or two days before the inbound Google search traffic will be arriving, suggesting that the software now directing search traffic from the infected websites may know in advance where the drop sites will be in advance.

Only Google?

It appears that Google is the only search engine with knowledge of these infected sites. We learned this by taking several domains that contained the infected Coppermine installs and used Bing’s site: command and Yahoo!’s Site Explorer; neither of these search engines returned any URLs which contained this particular exploit in action, suggesting that Google is the only major search engine being used as the attack vector by these malware distributors.

It is possible that the attackers took advantage of the ability to submit .xml sitemaps in Google to stimulate the search engine to visit and index the rogue blogs’ postings. A suitable .xml file was found on the sites examined to support this technique.

What Can Be Done?

Cyveillance recommends that Google investigate all URLs in its main index which contain albums/bsblog/category or bmsblog/category in the URLand take the appropriate action to minimize the potential danger to users. Additionally, webmasters need to ensure that software is constantly kept up-to-date with the latest revisions and site content is periodically reviewed for potential malicious activity.

While not necessarily practical, users can minimize the exposure to the attack vector described in this writing by copying and pasting the link in the Google search results directly in their browser rather than a directly clicking on the search result link. Additional steps to minimize the harm from the attack vector are ensuring all computer software is up-to-date and practicing safe Web surfing habits.

Heading in to 2010 and beyond, Cyveillance will continue to make the investments in personnel and technology needed to warn the Internet community of new threats, protect our customers, and stay one step ahead of the bad guys.

Google Sidewiki: The Early Days

Wednesday, November 4th, 2009

In late September, Google introduced Google Sidewiki. Sidewiki is, simply put, “a browser sidebar that lets you contribute and read information alongside any web page.” Currently Sidewiki is only fully available in Firefox and Internet Explorer but it is expected that Safari and Google’s own Chrome browsers will be supported in short order.

The reaction in the online community to Google Sidewiki has been mixed. The consumers who are aware of Sidewiki seem indifferent or positive about Sidewiki but the reaction among brand managers, marketers, and some webmasters ranges from apprehensive to hostile. Certain industries like pharmaceuticals are watching especially closely as they hash out what types of legal responsibility they may have to report adverse drug reactions that are published in Sidewiki.

Of course, like any place online, if there is a place to present content, spammers will attempt to take advantage of it. As Danny Sullivan wrote, “not all comments are created equal”, and Google is aware that it must dedicate resources to handling Sidewiki “contributions” that are spam or even more dangerous to end users. Sidewiki, like blogs, forums, Twitter, and other harbors of user-generated content online, could be a viable medium for spreading malware online. The impetus is high for Google to successfully determine what Sidewiki contributions are not dangerous to end users.

spam-porn-profile-screensho
Sidewiki spam created to drive traffic to pornography websites. Warning: adult language.

Digging a Little Deeper

In an effort to understand the adoption of Sidewiki, Cyveillance began watching the directory on Google.com where Sidewiki entries are being archived for users to view even if they do not have Sidewiki installed on their browser. Beginning on October 13, on a daily basis Cyveillance searched the directory where Sidewiki entries are stored by searching site:google.com/sidewiki/entry, and noting how many results Google said existed for these Sidewiki entries at the top of the page in the statement, “Results 1-10 of about (number)”.

A couple caveats for the experimentally minded: the queries were not made at the same time every day, and were not always performed from the same geographic origin. However they were done in both Safari and Firefox, while logged in to Google and logged out, to see if these made any difference in the results. The query was also performed from an iPhone for good measure. Here is a screen capture of the results for October 24th.

googlesidewiki10-24
On October 24th, the directory of Google Sidewiki contributions contained 1,130 entries.

The number of results did occasionally differ depending on the browser used and whether the experimenter was logged in to Google when the query was made. However the differences were negligible and can probably be attributed to the query momentarily being routed to a different Google data center that was just a bit out of sync with others.

number of Google Sidewiki entries
Number of Google Sidewiki entries over time when queried from Firefox while logged in to Google. (No query was made on November 17th.)

A couple of interesting details come from the above chart, which displays results returned when the site:google.com/sidewiki/entry query was performed in Firefox while logged in to Google.

  • The number of Sidewiki contributions appears to actually have decreased over time. This is surprising as the number would be expected to rise while more users contribute more Sidewiki edits.
  • The directory claims to be empty as of October 31. Since October 31, Google has returned the query saying there is nothing in that directory: “Your search – site:google.com/sidewiki/entry – did not match any documents. “

Why does it appear Sidewiki usage slowly decreased over time? Perhaps there was an initial rash of spammy or low quality contributions that were being culled from the results as Google tweaked its ranking algorithm for Sidewiki contributions. Still, it is surprising that (at least according to those results) there was a net loss of Sidewiki comments.

More importantly, where did the Sidewiki contributions go on October 31? They were not erased completely or put somewhere else like google.com/sidewiki/author. They still exist in the subfolder google.com/sidewiki/entry, as can be seen in this example, this example, and this example.

Did Google remove results from the subfolder google.com/sidewiki/entry by modifying its robots.txt file? A quick check of Google’s robots.txt file from October 31st has no mention of any sidewiki folder, so it is indeed intriguing why a query of the folder states there is nothing in there. (On October 31 there was a Halloween theme to Google’s robots.txt file but nothing excluding URLs from any /sidewiki folder.)

What Does It All Mean to You?

Luckily for brand owners, the surprising results are not likely to be the result of an intentional effort to make Sidewiki contributions hard to find, but rather a reflection of internal shuffling as Sidewiki is fine-tuned. One example of the tweaking that Sidewiki is undergoing can be found on the Sidewiki leaderboard pages, which currently have an “under construction” notice (you can see their earlier incarnation here). The service is just over one month old, and it is unrealistic to think that the way it is offered at the beginning will be the way it looks even six months after release.

In any case, Cyveillance recommends that enterprises be aware of Sidewiki in these early days and moving forward to monitor closely what visitors are saying about your organization. It is one thing for someone to complain about your organization on their own blog, but it is another thing entirely for that person to be able to write whatever they want on what feels like your actual site. For the proactive types, you can also submit product ideas for Google Sidewiki, for example, where the push to make Sidewiki opt-in for websites (instead of automatically available for Sidewiki comments) seems to be a popular suggestion.

UPDATE November 5: It may be that the reason that Sidewiki entries were not appearing in search results for the query site:google.com/sidewiki/entry was because they added noindex, nofollow to the meta tags of those pages. However it appears they also added Disallow: /sidewiki/entry/ to their robots.txt file within the last 24 hours as well.