Risk
8/5/2010
03:45 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

The Browser As Attack Vector

Beginning with the Web 2.0 boom and accelerating with today's popular SaaS model, new attack techniques are exploiting browser flaws and leading to the compromise of data.

For years, we groused about bug-ridden browsers while initiatives to harden them largely fell flat. Then one day, IT woke up to find that the browser is the new OS. Web 2.0 applications use browsers and the public Internet to create interactive interfaces and enable asynchronous collaboration, inside and outside the firewall. Google Chrome is promising to push Web-based operating systems forward, which could let businesses cut costs and infrastructure.

All types of companies are moving toward software as a service at a steady clip--55% of the strategic IT managers responding to our June InformationWeek Analytics Cloud Computing & IT Staffing Survey of 828 IT professionals are using SaaS or plan to. What all that means is, the browser is now your employees' gateway out--and an attacker's gateway in. IT must focus on protecting the browser from compromise without hindering functionality and derailing business initiatives in the process.

If you read "protect the business" as "patch servers, add rules to the firewall, and apply system configurations," you're asking to be breached. Browser-based attacks are a significant challenge, for a few reasons. They're unpredictable. IT doesn't always know where a user will need to go on the Internet, what services need to be accessed, and when. This makes defense by tightly limiting where employees may surf very difficult. User errors are often factors in successful exploits. And attackers are smart and resourceful and frequently compromise seemingly innocuous sites. All the monitoring and training in the world may not make a whit of difference.

What does matter: Putting in place a comprehensive protective strategy that's both proactive and reactive.

Browser Blitzkrieg

What's that? You're having trouble getting funding for the security initiatives already in place, never mind a new program? Then some education is in order, because browser-based attacks are at your doorstep. We've seen real-world examples: The New York Times last September was found to be serving malware through a third-party online advertisement network. The attack against Google in China, nicknamed Operation Aurora, is believed to have utilized a zero-day, or previously unknown, flaw targeting Internet Explorer.

Attacks against, or via, the browser vary in type and sophistication. The most basic simply ask the user to download a malicious file disguised as something legitimate. As users become more savvy, they fall for these attacks less and less. More sophisticated attacks involve directing people to malicious sites through links placed in the comment or advertisement sections of legitimate sites. Once the user visits the malicious site, code is loaded automatically that attempts to exploit security holes in the browser, or a browser plug-in, such as Flash Player (see how that could happen in the diagram at left). These attacks are called "drive-by downloads," and even wary end users can be fooled.

Really sophisticated attackers remove one key step--they compromise a legitimate site and load malware directly from there. This is always more effective than hoping a person will click a link and navigate to a malicious site. Recently, attackers have found that an even faster and easier way to infect legitimate sites is to purchase advertising on the site, as happened with the Times, then load their malicious code into advertisements. This gives the attacker a legitimate distribution channel without the hassle of compromising a site, setting up a malicious site, or recruiting people to click on links. Web anti-malware company Dasient, in its most recent quarterly report on Web malware data and trends, reports a spike in "malvertising" attacks since the beginning of this year, and we have no reason to think that rates will go down, seeing as just about every knowledge worker on the planet has an least one browser open at all times.

En Garde

Since these threats come from outside, effectively protecting our users, and in turn our data, requires a two-pronged strategy:

1. Taking steps to reduce our exposure to these threats, and

2. Being ready to respond quickly and decisively to inbound attacks.

Proactive protections can be the most effective but also the most difficult to implement. When people visit a malicious site that attempts to exploit the browser, a few stars must align to make the attempt successful. First, the user's browser must be capable of executing the malicious code. If the site uses ActiveX to exploit a flaw in the browser or OS, for example, then the browser must have support for ActiveX enabled.

Next, the user must have permission to perform the action the malicious code is attempting. If the malicious code attempts to write to the system registry but the user doesn't have registry access, then that part of the attack fails. Because of this, the most common recommendation to stop these attacks is to remove administrator privileges from end users. If the user can't damage the system, the malicious software can't either, in most cases. There is the rare instance where multiple exploits are stacked to overcome privilege limits, but most often the attacker assumes the user will have the required permissions.

Obviously, limiting privilege is a great idea, and highly recommended if you can swing it. But it's also a hard sell because, inevitably, it breaks some applications or restricts end users to a degree they find intolerable. The result is that companies tend to get tremendous pushback from employees when trying to implement such controls.

To remove the ability for the browser to execute malicious code, some companies have disabled technologies commonly used in these attacks, including ActiveX, JavaScript, and even Flash and Silverlight. As with limiting privileges, this can hinder users and reducing the functionality of many Web applications. If you use Mozilla-based browsers such as Firefox, add-ons such as NoScript and AdBlock Plus attempt to block browser-based threats from these technologies while still allowing trusted applications to function properly. This approach is a good middle ground.

One sure-fire way to protect against known weaknesses is to ensure browsers and browser plug-ins are always updated when patches or new versions are released. You probably pay attention to ensuring operating systems are patched and updated; browsers rate the same level of attention.

To go a step further, some IT groups sandbox the browser. There are two ways to do this; we discuss them in our full report, at informationweek.com/ analytics/browsersecurity. The first is using the operating system's ability to run the browser as a separate, lower-privilege user. Or the browser itself can be run in a sandbox, allowing it to function but restricting it from accessing any other portion of the OS.

Protection Plan

Once you've done your part, go train employees in three areas:

Check it out: Most browsers enable us to check Web sites against a third-party register, typically Google's Safe Browsing list, to determine if the site is known to host malware. Use this ability.

Rules matter: Make a policy that when warnings appear, users don't ignore them. Warnings exist for a reason. Explain that browsers may be exploited automatically on page load. It's never OK today to download free MP3s on a work system or click yes in pop-ups promising pictures of Lady Gaga.

Reinforce your defenses: Regularly discuss the evolution of threats and keep policies current. Attackers aren't sitting still, and you can't either.

Adam Ely is an InformationWeek Analytics contributor. Write to us at iweekletters@techweb.com.

[BROWSER SECURITY]

Get This And

All Our Reports

Become an InformationWeek Analytics subscriber for $99 per person per month, with multiseat discounts available, and get our full report on browser security at informationweek.com/analytics/ browsersecurity

This report includes 14 pages of action-oriented analysis.

What you'll find:

> Detailed information on ways to protect data from attacks entering through browsers

> Analysis of the effect growing use of SaaS has on browser choice--and security

> Why Web filtering is more important now than ever

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0640
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote authenticated users to bypass intended restrictions on resource access via unspecified vectors.

CVE-2014-0641
Published: 2014-08-20
Cross-site request forgery (CSRF) vulnerability in EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to hijack the authentication of arbitrary users.

CVE-2014-2505
Published: 2014-08-20
EMC RSA Archer GRC Platform 5.x before 5.5 SP1 allows remote attackers to trigger the download of arbitrary code, and consequently change the product's functionality, via unspecified vectors.

CVE-2014-2511
Published: 2014-08-20
Multiple cross-site scripting (XSS) vulnerabilities in EMC Documentum WebTop before 6.7 SP1 P28 and 6.7 SP2 before P14 allow remote attackers to inject arbitrary web script or HTML via the (1) startat or (2) entryId parameter.

CVE-2014-2515
Published: 2014-08-20
EMC Documentum D2 3.1 before P24, 3.1SP1 before P02, 4.0 before P11, 4.1 before P16, and 4.2 before P05 does not properly restrict tickets provided by D2GetAdminTicketMethod and D2RefreshCacheMethod, which allows remote authenticated users to gain privileges via a request for a superuser ticket.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.