Last year, we noted that Adobe took the important step of enabling automatic updates by default for new installations of its free, widely used Reader product. Existing installations, however, maintained their existing settings. Because previous versions of Reader defaulted to downloading, but not installing, updates, many computers are still running outdated versions that are prone to drive-by downloads and other malicious threats.
It therefore comes as good news that Adobe will now prompt users to switch to the more automatic setting:
While the Computerworld article describing this change compares the behavior to the Chrome browser's silent update feature, Adobe is making a clear effort to respect users' choices more explicitly than Chrome does. Not only are users prompted to opt into this feature in Adobe Reader, but there are other options available for those users who wish to opt out. Chrome, in contrast, makes this a default with no notification to the user, and there is no setting within the user interface to disable or change it.
As we discuss in our recent State of Badware report [PDF], Adobe deserves credit for taking several steps over the past year or so to make it easier for customers to keep their products patched.
Today, StopBadware is proud to announce the public release of our first State of Badware report. The State of Badware offers insight into recent badware trends and responses and examines the factors that contribute to badware’s persistence.
Badware is a significant challenge for all members of the Internet ecosystem, from individual computer users to big businesses and world governments. Cybercrime has evolved into a complex, profitable economy, and badware is the tool of choice for cybercriminals who perpetuate this economy. Despite the considerable resources poured into attempts to eliminate it, badware is, by all accounts, still on the rise. We believe that to truly understand the badware threat, it’s necessary to look at the interconnected systems that are tasked with defending against badware: The State of Badware explores four major areas of vulnerability—technical, behavioral, economic, and legal—in the Internet ecosystem’s overall structure that contribute to badware’s perseverance.
It’s clear that the today’s approaches to security aren’t enough to repel or eradicate increasingly dynamic and hard-to-measure badware; we must create new and more centralized methods of measuring and responding to this threat. The State of Badware highlights key opportunities for improvement: it is intended as a resource to help individuals, business leaders, and policymakers understand how both badware and the industry’s response to it are evolving—and what steps we can take to defend against it.
You can read the full press release here. We at StopBadware are excited about this report–both its release and its potential as a tool for those who want to take action. As always, we welcome thoughtful discussion. You can download the full State of Badware at http://stopbadware.org/pdfs/state-of-badware-june-2011.pdf.
We at StopBadware are happy to officially welcome SoftLayer as our newest sponsor! SoftLayer Technologies is the largest web hosting company in the world. They’ve recently supported StopBadware by contributing to the development of our best practices for web hosting providers, and we’re excited to be taking the next step with them. Welcome, SoftLayer!
The following is a guest blog post by Denis Sinegubko, a malware researcher, security blogger, and software developer. Denis is the creator of Unmask Parasites, a free tool for checking websites for badware.
Matt Cutts, the head of the webspam team at Google, recently tweeted about a new black hat SEO trick:
“A recent spam trend is hacking websites to insert rel=canonical pointing to hacker’s site. If U suspect hacking, check 4 it.â€
If Matt Cutts pays so much attention to this and calls this a trend (not just individual cases) it’s definitely something worth looking into. So I decided to find more information about this “canonical†issue.
What is rel=canonical?
As you might know, rel=canonical is a way for webmasters to tell search engines where they can find the original (canonical) copy of a web page. This helps avoid indexing multiple duplicates of virtually the same content.
Here are some typical uses of this instruction:
The same page can be accessed via multiple URLs on the same site (e.g. page can be found in multiple categories) and one URL can be specified as canonical.
A website maintains multiple mirrors on different domains and a webmaster wants only the main site to appear in search results.
A website moves to a new domain but there are some technical problems with setting up real 301 redirects (e.g. free hosting service that only allows editing of HTML files).  In this case, rel=canonical can help search engines find the new address of the website and make that address preferred.
While rel=canonical has proven to be a very useful tool to eliminate duplicates in search results and make important pages rank better than derivative pages with similar content, like many other tools, it can be abused.
“Canonical†black hat SEO trick
In this case, cyber-criminals may hack legitimate web sites and inject “canonical†instructions that point to a third party website. For example, they can inject the following tag into a web page on a hypothetical good-hacked-site.com:
When Google finds this instruction, it thinks that the page has moved to a new location or that it is a duplicate of a page on bad-site .com.  And if that page on the bad-site.com looks similar to the hacked page (it’s quite easy to copy it), Google will eventually replace good-hacked-site.com results with results that point to the bad-site.com.
Effectively, this way hackers can hijack search results of a legitimate web site. Now bad-site.com has all the search traffic of good-hacked-site.com, and good-hacked-site.com is no longer visible in search results. Typical parasites.
So what benefits can bad-site.com have if it needs to have web pages with the same (similar) content as web pages on good-hacked-site.com? Isn’t it a serious limitation of this black hat SEO scheme? Actually, no.  Criminals don’t have to play by the rules of search engines. Nothing can stop them from from serving different content to search engine bots and to real visitors. Such shady servers can use cloaking to make search engines believe that they contain pages with similar content, but for real human visitors they have something more “interestingâ€, e.g., pages that push fake AV or malicious fake codecs (to watch some video),or redirects to other malicious and scam sites. Or they can leave the same content and add their own ads just to monetize the traffic. If criminals manage to inject rel=canonical instructions pointing to bad-site.com from thousands of legitimate sites, they can eventually expect a decent amount of search traffic. So it is well worth the effort.
Crotopole.eu – the canonical hack in the wild
As Matt Cutts mentioned, this sort of hack is not just something hypothetical. I was able to find a few discussions where webmasters talk about how their sites lost ranking in Google and how they found rogue rel=canonical instructions pointing to crotopole .eu.
The hacked web pages contained one additional line of HTML code:
The numbers in the malicious URL vary from site to site. And here is why: they are actually an MD5 hash of the web page’s URL. You can see it in the following snippet of PHP code that hackers inject into legitimate files.
function callback($buffer){
return (str_replace("", "
\n", $buffer));}
ob_start("callback");
In addition to the sites mentioned in those discussions, I was able to find a few more similarly hacked sites that still have those “crotopoleâ€rel=canonical instructions.
One interesting note: it is easy to miss the rogue link tags with crotopole .eu canonical URLs when you examine the HTML source code of the web pages.  Take this screenshot. This is what HTML source code of infected pages normally looks like:
Can you see a rel=canonical instruction? No? But it is there! On the line right above the tag. The reason you can’t see it is that there are 25 invisible tab characters that shift the rogue tag to the right, far off the visible part of the source code. You can only see it if you scroll horizontally (which people don’t usually do) or if your code viewer has an enabled auto-wrap function (which happens quite rarely).
At this point, crotopole .eu is not responding. Google has already removed it from its index. This eventually happens to all black hat schemes. But they produce decent short term results, so we can expect new, slightly modified attacks in future.
(Side note: The crotopole. eu domain belongs to people who operate the infamous “picsdiggerâ€Â network of spammy hot-linking sites that hijack Google image search results of image owners.)
301 redirects vs canonical hacks
This new “canonical†hack resembles an older “301 redirect†hack where criminals configure compromised sites to redirect search engine crawlers to third-party sites using the “301. Moved permanently†status code. Search engines interpret this as a signal that a web page has moved permanently to a new location and search results that pointed to this page should now point to a new page on a different site.  This way, attackers manage to hijack search results, leaving compromised sites without their search traffic.
Both hacks may be quite difficult to detect since they don’t affect site functionality. The 301 redirects are only visible to search engine crawlers and the rel=canonical instruction is not something webmasters will regularly check their web pages for (even those who know what this rel=canonicalthing is).
Diagnosing “301 redirect†and “rel=canonical†hacks
Nonetheless, careful webmasters can diagnose such problems if they see dramatic changes in search traffic.
The #1 tool to diagnose all site problems that involve cloaking (including 301 redirects) is the “Fetch as Googlebotâ€Â tool in Google Webmaster Tools. It will show you what Google sees when it tries to index your site.
Another useful feature in Webmaster Tools is the warnings for redirecting URLs found in your sitemap (Sitemaps are supposed to contain only links to final, not redirecting web pages).
As far as I know, at this point,  Google Webmaster Tools don’t provide information that can reveal rel=canonical hacks. But they are aware of the problem and currently working on making rel=canonical issues more visible in Webmaster Tools.
Meanwhile, you should regularly check your web pages specifically for undesired rel=canonical instructions. It helps if you use some integrity control system for your server files. This way you’ll know when someone modifies your files and will be able to revert unwanted changes before Google notices them and removes your site from search results.
Are canonical hacks a serious problem?
The good news is this trick may not work well for hackers all the time. Matt Cutts writes:
“Another example where we might not go with your rel=canonical preference: if we think your website has been hacked and the hacker added a malicious rel=canonical.â€
However, these words are not a reason to take “canonical†hacks lightly. One reason is that hackers can make everything look quite legitimate and have Google overlook the hack. But the main reason is that such rogue instructions in the HTML code of your web pages are a strong sign of serious security problems. If hackers can modify files on your server, imagine what else they can do! If the rel=canonical trick doesn’t work for them, they can try to abuse your site in some different way: inject spammy links or malware, create phishing pages, steal the databases of your clients, or even destroy your site.Â
So if you don’t want to lose your search traffic, lose your customers, or lose your whole site, make sure to monitor your web pages for unwanted changes (including rogue “canonical†instructions).
The other day, the JoshMeister blogged about the Mac App Store and the effect of its approval delays in getting critical security updates to users.
Third-party Web browser maker Opera has released version 11.11 of its software, which fixes a “critical” security issue. Mac users who have downloaded Opera through the App Store may find themselves using a copy of Opera that is now two versions old, 11.01, which was released back in March and is vulnerable to the security bug patched in 11.11. Users who rely on the App Store to tell them whether their software is up-to-date may not be aware of the security risks and may continue to use an unsafe version of the Opera browser.
As the app store model becomes more popular on both smartphones and PCs, it’s important to explore issues like this. What the JoshMeister doesn’t mention is that centralized app markets can also help encourage users to keep software updated. It’s much easier to have a single marketplace app, once per day or week, say “here are all the apps that have updates, click to update them all” than to have to manage each app individually. If this encourages users to keep their apps up to date, that’s a positive thing for security.
Of course, this model requires two conditions to work effectively from a security standpoint. First, the updates have to be made available to users through the store in a timely fashion. Second, the updates have to be screened to ensure they’re not violating the market’s standards (e.g., they’re not badware). Based on the delays observed with the Opera updates and other submissions to the Mac App Store, it seems that there is some tension between these two conditions. If critical updates for known vulnerabilities take substantially longer to get to users via the store than they would through an app’s only automatic update mechanism, something needs to be fixed.
One potential improvement could be to allow vendors to flag certain app updates as containing high priority security fixes. The store could then prioritize those updates for approval. Of course, this could (and probably would) be abused on occasion by vendors trying to rush updates out to users, but I’d like to think such abuse wouldn’t be so frequent as to be a major problem.
Another approach would be to prioritize approval of updates based on the popularity of the application. This would ensure that the most widespread apps would get patched more quickly than less used apps. I don’t generally like options that give established vendors preferential treatment over new entrants to the market, but experience teaches us that criminals like to target badware at widely installed software.
Of course, the cynical side of me says that Apple and other operators of app markets care more about getting new apps into the market than getting security updates out to users. After all, new apps mean new revenue opportunities, as well as bragging rights. (“We have x apps in our store; our competitors only have y.”) On the other hand, just as supermarkets get bad press and lose customers if they fail to take recalled products off the shelves, application stores may find their reputations suffering if users start facing security threats that could have been avoided. Here’s hoping this will be enough incentive to get those stores to find solutions to getting critical updates out to users quickly and safely.
Good news! StopBadware has a last-minute opening for a summer intern here in our badware-repellent office in Harvard Square. Our summer intern will:
learn how to spot badware in websites
contribute to the security community’s knowledge of badware trends
hang out with cool geeks in a big open office
The exact length of the internship is somewhat flexible, but we’re looking for someone who can start as soon as possible, so get your application in today! You can read about the full job description here.
AV-Comparatives is a non-profit independent lab in Austria that attempts to accurately evaluate anti-virus software. This is harder than it sounds. In fact, an entire organization called the Anti-Malware Testing Standards Organization (AMTSO) sprung up a couple years ago to provide guidance on accurately testing security software. (Note: I serve on the advisory board of AMTSO.)
AV-Comparatives recently conducted an interesting survey of visitors to their site. They attempted to filter out spam responses and those from people within the AV community, which I guess means they mostly captured consumers and tech geeks that care enough about the subject to look up reviews of AV products.
To me, the most interesting bit of the survey was the question "Which type of tests are you most interested in?" Respondents were asked to choose up to four types of tests from a field of twelve. Let's look at a subset of the results:
Detection Rate (On-Demand) Test
By far the highest vote getter, 84% of respondents chose this as the type of test they're most interested in. Note that this is a test that searches for and finds malware that is already on your computer when you choose to run a scan. It doesn't evaluate the ability of the software to protect your device from being infected in the first place.
Performance Test
Oddly, 77% of respondents felt that AV vendors should try harder to improve AV software's performance impact on computers, yet only 51% wanted to see more testing of AV software's performance impact. Don't they say that what gets measured gets done?
Whole-Product Dynamic Test
This is the only test from the list provided that actually attempts to evaluate whether an AV product keeps malware off your computer under conditions that simulate real use. This seems like a good thing to know when selecting AV software, yet only 40% of the survey respondents wanted to see this type of test. Maybe they didn't know the terminology?
False Alarm Test
Many security experts (including me) believe that alert overload, or "boy who cried wolf syndrome," leads to users ignoring warnings and putting their computers and data at greater risk. Yet only 32% of the survey respondents thought that false alarm tests should be a priority. Maybe people feel that they'd rather the software be safe than sorry?
Because there isn't much qualitative information accompanying the data from the survey, it's hard to accurately interpret these findings. My sense is that, at least for this self-selected population, there may be a gap between the users' understanding of how modern AV software—and modern AV testing—work and how they currently perceive it. Then again, it could just be confusion about terminology, or a population that is skewed towards an unusual usage model.
In any case, if you'd like to understand a bit more about the present and future of AV software, and how it's tested, you should read the full survey here. [PDF]
Just like millions of other people around the globe, we at StopBadware woke up today to headlines trumpeting the highlights of the wedding of Prince William and Kate Middleton. It’s not just the British who are riveted to this once-in-a-lifetime event: over at Google Trends, “royal wedding coverage†is the number one “Hot search†in the United States right now. Sadly, the fervor the wedding is generating creates a plum opportunity for cybercriminals to deliver malware to unsuspecting Internet users—and, sure enough, they’re taking it.
As a quick experiment, we decided to load up Internet Explorer and take a quick look around to see what it would take for a curious searcher to run into a malware distribution point. To show how quickly and effectively we were able to do so, we made a short video:
From a Google Web Search page (note the celebratory Doodle), we entered “royal wedding coverage†into the search bar. Google offers us news, videos, and approximately 41.6 million other results, but let’s say the user is interested in pictures. Clicking over to Google Image Search, we see a number of pictures of regal couples. Since everyone’s abuzz over the royal bride’s gown, we look at the third photo in the lineup, captioned “Royal Wedding Gowns Photosâ€. It’s easy not to notice the domain name hosting that image: kiwiblitz .com. Perhaps it’s a bit odd, but not necessarily enough to trigger a user’s suspicions. Clicking the image brings us to the familiar Google Image Search frame and what seems to be an empty content frame. All of a sudden, the window closes, and a warning box pops up: “Warning! Your computer contains various signs of viruses and malware programs presence. Your system requires immediate anti viruses check! System Security will perform a quick and free scanning of your PC for viruses and malicious programs.â€
The rest of the video speaks for itself: it’s a classic push for Fake AV, or malware masquerading as security software.
But what happened with that click?
Google Image search identified the image as residing on
http://www.kiwiblitz. com/gnRoyal-Wedding-Photos/
and loaded that URL in an inline frame. Kiwiblitz appears to be a weekly webcomic, hosted by Dreamhost; we have no reason to believe the site’s legitimate owners intended for this URL to exist. Rather, an attacker appears to have exploited a weakness in the site’s security model and inserted a redirect for the URL above, pointing the browser to a very different URL:
nyzjgyt .co.cc is a subdomain of co.cc, a Korean company specializing in offering low-cost bulk registration and redirect services. The subdomain resolved to IP address 193.105.134.92, hosted by Portlane, a Swedish hosting provider. The request returned the obfuscated JavaScript responsible for closing the search window, “alerting†the user, and displaying the false initial scan. When the false security alert is clicked at the conclusion of the ‘scan’, the browser sends the following HTTP GET request:
We submitted the executable to VirusTotal for analysis by automated antivirus engines; only 4 of 42 engines identified the file as a threat. Microsoft’s antivirus detection engine reported the file to belong to the Win32/FakeRean family, which disrupts users’ ability to browse the web and prompts them relentlessly to “purchase a license†for the Fake AV software. If a user agrees to do so, Internet Explorer will open (with the URL bar conveniently hidden) and load content from the following page:
http://vupuhuzyniw. com/buy.html
vupuhuzyniw. com was registered yesterday and loads content from 76.73.85.82, hosted by FDCServers.net in Chicago. The registrant purports to be someone in the south of France, though likely this is fake or stolen information. Any users who submit their credit card information into the form on this site at the behest of the Fake AV software are at substantial risk of suffering credit card fraud and identity theft.
Although the payload from this attack can be extremely annoying and costly—it makes the PC all but unusable—this sort of attack is certainly not of the most sophisticated or technically dangerous variety. A user who does not download or run the Fake AV executable does not appear to suffer compromise, and the payload does not appear to exfiltrate user data or install other malware. However, it does highlight the number of stakeholders in the Internet ecosystem with proverbial skin in the game.
We have reported the image search result to Google and are taking steps to notify the parties that appear to be unwitting participants in this scam. As always, we urge users to exercise caution when searching, even—and especially—when looking for popular content.
Last month, we released a set of best practices for hosting providers responding to malware reports. The best practices are intended to address inconsistency within the industry about how to responsibly and effectively respond to malware reports; they lay out a high-level framework that web hosting providers of all sizes can follow. Today, we at StopBadware are pleased to announce that we have already begun to take the logical next step in helping to strengthen the Web ecosystem: developing a set of best practices for malware reporters.
This second set of best practices will provide a high-level framework for reporting URLs that host, link to, or deliver malware. Developing best practices for malware reporters is a natural continuation of our work in the web hosting arena, and we expect this new best practices document to complement and enhance our best practices for web hosting providers. It’s our hope and expectation that this new effort will help security researchers and corporate IT departments communicate effectively and efficiently with hosting providers, site owners, and other relevant parties. We also expect the process of developing best practices for malware reporters to serve as a strong foundation for a new centralized reporting system we at StopBadware are planning to build.
Our best practices for web hosting providers were developed with the advice of an advisory working group that included representatives from top hosting providers, security companies, and policy organizations; this group ensured that the Practices were sensible and complete, but perhaps of even greater value was the discussion and collaboration that arose among the group’s diverse members as we worked to formulate the final document. Given the level of engagement and the quality of the discussion produced by our Web Hosting Working Group, it was an easy decision to assemble a second equally diverse working group to assist us in developing our best practices for malware reporters. We’ve already opened discussion with our Malware Reporting Working Group, and we look forward to listening to their insights over the next few months.
We’re extremely excited to be focusing on this project: it strengthens another crucial in the Web’s chain of trust, it encourages the high-level discussion we’re happy to be known for, and it’s a perfect example of the kind of collective action StopBadware’s mission is all about. We’ll likely be releasing public drafts of our best practices for malware reporters in the near future, so stay tuned or subscribe to get the latest updates and requests for comment.
In the past couple months, we’ve come across some particularly informative and well-written reports and articles about badware. Here, for your reading pleasure, are a few of our favorites:
This monster of a report by the European Network and Information Security Agency clearly describes the current state of the fight against botnets. It includes the techniques and challenges of detection, measurement, mitigation, and takedown.
Another outstanding report by ENISA, this document outlines and prioritizes the risk factors inherent to mobile deviecs (e.g., smartphones) and key strategies for addressing them.
From 2008 to 2010, a group of security researchers organized themselves as the Conficker Working Group to fight the badware known as Conficker. After the group’s work ended, the U.S. Dept. of Homeland Security commissioned a study by The Rendon Group to identify the lessons learned during this effort. It’s a great read that evaluates an unusual and reasonably effective cooperative effort.
