Volume XII of the Internet Security Threat Report (ISTR)is now out. In this report, we discuss how attackers have been usingtrusted Web sites as a means of reaching their victims. This trend is,in part, facilitated by something that we call “site-specificvulnerabilities”, which are vulnerabilities that are limited to aparticular Web site or service. These vulnerabilities are typicallypresent in the proprietary Web-based applications that drive theservices provided by the site.
What initially tipped us off to the increasing prevalence ofsite-specific vulnerabilities was actually a drop in the proportion ofWeb application vulnerabilities. In this report, we observed that 61percent of vulnerabilities affected Web applications, which is a dropfrom the 66 percent in the previous report. (Our discussion of Webapplication vulnerabilities includes only those Web applications thatcan be downloaded and installed within a third-party organization. Ournumbers don’t include vulnerabilities that have been reported in hostedservices like Blogger or Hotmail. However, one cannot ignore the recentemergence of forums for disclosing site-specific vulnerabilities suchas sl.ackers.org and XSSed.com.)
Shame for fame
Site-specific vulnerabilities are disclosed in a number of ways. Oneapproach is what I like to call “shame for fame”, which has beenemployed by researchers in various “Month of … bugs” projects. This isa publicity stunt that is typically meant to embarrass the vendors intofixing the bugs and draw attention to the security researchers involvedin their discovery. Site-specific vulnerabilities have been featured inthe Month of MySpace Bugs and the Month of Search Engine Bugs. Thesevulnerabilities are a good subject for this type of disclosure becausethey’re easy to discover and have the potential to get better mediacoverage than disclosing vulnerabilities in obscure Web applicationsthat may affect a handful of users. Since they potentially make abigger splash, the researcher benefits from the publicity.
The perils of disclosing site-specific vulnerabilities
Other researchers try to work with site maintainers to fix thevulnerabilities prior to disclosing them. However, if they do notobtain prior authorization to perform a security check from them, theyrisk breaking the law. There is no safe haven for the researcher toreport vulnerabilities discovered during an active audit orinadvertently in such a case. If they’ve discovered a vulnerability inthe Web site, they’ve technically attacked the site. Moreover,site-specific vulnerability research can’t be performed in a labenvironment, so there is always the likelihood that the researchercould disrupt or damage the site in some way. What is a securityresearcher to do? Some security researchers acknowledge the risk andadvise others to steer clear of researching site-specificvulnerabilities. This chilling effect may ultimately hurt the vendor ifthey found out about vulnerabilities after they have been exploited byattackers.
Site-specific disclosure policies
Some vendors, such as Google and Microsoft, have been pro-active inencouraging security researchers to report vulnerabilities in theirsites. To facilitate this effort, these vendors have set up pagesinstructing people on how to report vulnerabilities and thank peoplewho have responsibly disclosed vulnerabilities. This is a step in theright direction because it provides researchers with assurances thatthere won’t be repercussions for responsibly disclosing vulnerabilitiesin these vendor’s Web sites.
Site-specific vulnerabilities in the wild
Attackers also have a vested interest in discovering site-specificvulnerabilities since Web users are getting more savvy. This meansthey’re less likely to click on links in unsolicited email or wanderunprotected into the nether regions of the Internet. So attackers havebeen compromising legitimate Web sites as a means of infecting userswith malicious software. Users expect well-known sites to be secure andare easily caught off guard by attacks and malicious content thatoriginates from those sites. This has manifested in mass compromises ofsites hosted by a common provider or in more subtle exploitations ofWeb application vulnerabilities in an effort to seed popular sites withmalicious content.
The upshot of these vulnerabilities is exploitation of trust, whichis a common thread in this volume of the Internet Security ThreatReport. We discuss it in our analysis of the rise of Web browserplug-in vulnerabilities, which have gained traction with attackersbecause of their integration into attack frameworks such as MPack.Browser plug-in and site-specific vulnerabilities go hand-in-hand, aswas demonstrated in a sophisticated phishing attack that exploited aMySpace and an Apple QuickTime vulnerability in tandem. Compromised Websites are an ideal distribution platform for browser plug-in exploits.Therefore, the sharp increase from 74 plug-in vulnerabilities in thesecond half of 2006 to 237 plug-in vulnerabilities in the first half of2007 is cause for concern. The combined pool of Web application andbrowser plug-in vulnerabilities creates a wide array of possibilitiesfor multi-staged attacks that exploit legitimate Web sites, user trustin those sites, and ultimately the users themselves.
Site-specific Web application vulnerabilities have found a place inthe ecosystem of malicious Internet activity because they play a keyrole in making attacks less obvious by exploiting the trustedreputation of legitimate sites. They’ve been implicated in Web-basedworms, malicious code, client-side exploits, data breaches, spam, andphishing. As different types of attackers converge on similar attackmethods and motivations, the broader issue of exploitation of trust hasalso become an important strategy in the attacker’s playbook.
For more information on the current state of the threat landscape, please check out Symantec’s
Internet Security Threat Report, Volume XII.