Confusing the Padlock and the Favicon in the Web Browser

Web browser makers are continuing to change how they display two visual elements that people have been taking for granted: the padlock that designates an HTTPS connection and the favicon that acts as the thumbnail of the website’s visual identity. These changes are aimed at helping to minimize the risk that a favicon that looks like a lock might instill a false sense of security.

Users of web browsers have gotten accustomed to looking for the padlock image as part of the URL to determine whether the connection is “secure.” The browsers have typically displayed the lock for HTTPS connections where the SSL certificate was properly validated. Most non-geeky people don’t know what aspect of security the lock is supposed to signify, but they have been trained to rely on it as a symbol of online safety.

Webmasters can specify favicons as tiny images that web browsers have displayed in the URL bar to reinforce the site’s digital identity. Unfortunately, computer attackers can display favicons that look like padlocks, fooling victims into thinking that they were using an SSL-encrypted and authenticated connection. One tool that can automate such an attack is sslstrip, and this category of attacks is described in the Black Hat presentation by the tool’s author.

Internet Explorer

Microsoft’s Internet Explorer (v9) displays both the padlock and favicon in the URL bar. The favicon is on the left of the URL and—assuming the connection is using HTTPS with a valid certificate—the padlock is on the right:

A malicious webmaster or an attacker who can interfere with the web session may be able to display a padlock favicon even for HTTP or an invalid HTTPS connection, fooling the victim into thinking that the connection is “secure.” The distinction of where the trustworthy lock should exist in Internet Explorer (to the right of the URL, not to the left) is likely to be lost on most people.

Google Chrome

Google Chrome doesn’t display the favicon as part of the URL, showing it only in on tabs and bookmarks. Chrome displays the lock icon in the URL bar (in several variations) for connections that use HTTPS.

Because Chrome doesn’t display the favicon on the URL bar, this browser’s users are being conditioned to place greater trust in the padlock image displayed next to the URL. This is good.

Firefox

Mozilla’s Firefox stopped displaying the padlock icon for HTTPS connections starting in version 4 of the browser, phasing it out in favor of the Site Identity Button. The current production (v12) and beta (v13) releases of Firefox still display the favicon the browser’s URL bar and on the tab:

In this setup, a website that doesn’t use HTTPS display a favicon that looks like a padlock in the URL bar, fooling the victims who associate the lock with safety into thinking that the connection is “secure.”

To help address this risk, the current nightly build of Firefox (v14) no longer displays the favicon in the URL, showing it only on tabs, bookmarks and Awesome bar suggestions, according to Firefox developer Jared Wein. This version of Firefox adds the padlock to the Site Identity Button, while preventing webmasters from placing a false lock icon in the URL bar:

The approach to eliminating the favicon from the URL bar and displaying the padlock there for valid HTTPS connections is consistent with the behavior of Google Chrome. It’s encouraging to see the two browsers using compatible visual approaches that are designed to minimize user confusion.

Opera

Fortunately, the behavior of Opera is consistent with how Firefox and Chrome display locks and favicons. Opera displays favicons on tabs and bookmarks, while displaying the padlock on the URL bar for appropriate HTTPS connections:

Safari

Unfortunately, Safari displays the padlock and favicon on the URL bar, as well as on tabs and bookmarks in a manner consistent with Internet Explorer. In other words, the favicon is displayed to the left of the URL and the lock, when appropriate, is shown to the right of the URL.

There’s room for continuing to improve the visual indications that browsers present to users for making security-related decisions. Internet Explorer and Safari appear behind times in their treatment of favicons, because they display these images in the URL bar. In the meantime, individuals who educate non-technical people in web safety practices should consider how to best explain the various security indicators in the URL bar. None of these are easy undertakings.

Hand-picked related articles:

• Mitigating Attacks on the Web Browser and Add-Ons
• Respect the Browser- Security Awareness Recommendations
• How to Design Security Warning Messages to Protect Users

— Lenny Zeltser

4 Free Tools to Detect Local Insecure Browser Plugins

Pursuing vulnerabilities in local software that is accessible through the web browser has been an effective attack vector. The following 4 free tools can help you identify locally-installed browser plugins that are behind on security patches.

Google Chrome and Secbrowsing

Users of Google Chrome rejoice—the browser flags common insecure plugins without the need for any additional tools. The alert appears when you attempt to load content that makes use of the vulnerable plugin:

If you’d like to be notified of outdated plugins proactively, even before Google Chrome has the need to use the plugin, install the optional Secbrowsing extension from Google.

Mozilla Plugin Check Page

Mozilla set up the Plugin Check page identify insecure plugins. The page works in Firefox as well as other browsers, and doesn’t require any tool installation. Mozilla provided some technical details regarding inner-workings of the server-side tool for those seeking additional information about it.

Qualys BrowserCheck

Qualys BrowserCheck is a free lightweight tool for scanning common browsers for vulnerable plugins. The tool needs to be installed locally, and is well documented by Qualys.

Secunia PSI

Secunia is well-known for Secunia PSI—a free local application to identify vulnerabilities in installed software. The tool is able to scan for not only insecure browser plugins, but also for vulnerabilities in other local software. The biggest issue with Secunia PSI is that the tool’s user interface is likely to be confusing for inexperienced computer users.

My Perspective

Secunia PSI rules when it comes to providing a comprehensive scan of local applications. In this, it exceeds the coverage of Qualys BrowserCheck, and would be my first choice if I were to install a scanner.

My kudos go to the Google Chrome team for building plugin-scanning capabilities directly into the browser. This approach has the potential of providing more complete and accurate results than the install-free Mozilla Plugin Check page, while providing the user with automatic alerting.

— Lenny Zeltser

Respect the Browser - Security Awareness Recommendations

Security awareness training usually incorporates web security topics. The message needs to be brief and relevant to non-techies, so they will pay attention. Consider focusing the audience’s attention on the browser—a tool that, for most people, personifies the web both at home and at work.

The title of this list was inspired by the Respect the Escalator safety poster I saw in the New York City Subway: Respect the Browser.

• Watch the typos. Use bookmarks for the websites you visit frequently to avoid arriving at copycat or otherwise malicious sites (in other words, paypal.com is very different from pajpal.com).

• Patch the software. Configure the browser and its add-ons, such as Flash and PDF reader, to automatically download install security updates.

• Use encryption. Make sure that the website address starts with HTTPS when sending sensitive data to protect it from being intercepted.

• Log out. To end a session with a sensitive website where you needed to log in, click the log out button. Simply closing the browser window might not be enough.

• Beware of public computers. Avoid accessing sensitive data when logging in from public systems, such as library PCs or Internet kiosks. They might be infected.

• Protect the browser. Use anti-virus software with features that include a browser security modules to block web exploits and flag malicious links.

If you could only share 6 brief web safety recommendations with non-technical computer users, how similar would your list be to mine?

— Lenny Zeltser

How to Design Security Warning Messages to Protect Users

Computer users are presented with a steady stream of security warnings, which are designed to help users avoid taking actions that put their systems and data at risk. Sometimes, a click on the OK button is all that stands between the person and an intrusion.

What are the characteristics of an effective security warning? Let’s take a look at some examples.

Microsoft Office Security Warnings

Consider this warning pop-up from Microsoft Excel 2003, which would appear when the user opened a spreadsheet that contained macros, but the macros were disabled.

The text in this warning is too long and technical. The message offers no convenient way to enable macros: even after the user clicks OK, the macros stay disabled. That may be good for security in the short term. In the long term, the user would probably enable macros globally, just to avoid having to deal with this message again.

Fast-forward to Microsoft Office 2010. The security warnings are much shorter and to the point, such as the one stating that “Macros have been disabled.”

The biggest concern I have with this message is that the button to enable macros is labeled “Enable Content.” Non-technical users may not equate content with macros and click the button. After all, content isn’t code, right?

Here’s another, similar security warning from Microsoft Excel 2010, stating that “Data connections have been disabled.”

I doubt many users will know what “data connections” are and will click “Enable Content” for the reasons I outlined above.

Below is a Microsoft Office 2010 security warning that I actually like. It occurs when the user opens a document downloaded from the Internet, in which case Office uses a restricted viewer called Protected View, instead of a full-featured editor.

The warning explains the issue clearly using words that most people will understand, explaining the reason for the security concern and providing a course of action.

Web Browsers’ Security Warnings

Here are a few examples of security warnings presented by web browsers. Consider the following message that Firefox 3.6 presents when the person finishes downloading an executable file.

Though the message presents no text of caution, at least there is no option to run the program—only an opportunity to “Save File”. In this case, the browser leaves it up to the OS to warn the user when he or she attempts to run the program downloaded from the Internet.

Here’s a similar message from Internet Explorer 8. It includes a warning, but leaves room for improvement:

The first button is “Run”, so that’s the one that will probably attract the user’s attention first. The fact that this is a security warning is “hidden” on the periphery of the dialog box: in its window title and the small footer text.

Recommendations for Designing Security Warnings

After surveying these and other examples of security warning messages, the following recommendations come to mind:

• Make the safest button (e.g., “Disgard”, rather than “Run”) most visible. This usually involves placing it first on the left, making it larger or highlighting it in a brighter color.
• Be brief. Users will ignore lengthy text, so include just a few necessary words in the main warning, giving people a chance to click a button for details.
• Include enough background details (e.g., the type of downloaded file) to help the person make a decision regarding the best course of action.
• Stay away from technical jargon that most users of the product won’t understand or will misinterpret.
• Don’t overwhelm the user with numerous warnings in a row. After a while, choice fatigue will prevent the user from selecting wisely.

Designing security warning messages is hard, because it often involves finding a compromise between conflicting goals, such as being terse while providing contextual details. Similarly, the developers need to balance ease of use with security. If you have recommendations or examples in addition to what I presented above, please leave a comment.

— Lenny Zeltser

Mitigating Attacks on the Web Browser and Add-Ons

Attacks on client-side applications also take the form of a malicious website targeting a vulnerability in the visitor’s web browser and its add-ons. Locking down the browser and the software it can invoke helps mitigate the risk of this attack vector.

Drive-by exploits against Java Runtime Environment (JRE) have been particularly effective lately, allowing code that runs within the browser to escape JRE’s sandbox and install local malware. Adobe Reader has been another common target. As another example, an Internet Explorer exploit released in mid-December was able to exploit a flaw in the browser by targeting a DLL that was not compiled with ASLR and DEP security features.

To make it harder for a malicious website to access the operating system of the visitor’s computer, Google Chrome and Internet Explorer ship with sandboxing features. Recently-released Adobe Reader X also includes a sandbox with the same goal in mind. The increased availability of such application sandboxes means that the attackers will need to utilize two exploits: one to affect the vulnerable browser or add-on moduile and another to break out of the sandbox.

Resisting exploits that target the browser and its add-ons also involves tightening the application’s settings, for instance to disable unwanted features and to configure trust zones. Enterprises need to be able to do this centrally, usually using the Group Policy feature of Active Directory. Internet Explorer supported Group Policy-based deployment and setup for a while. Google Chrome now supports Group Policy as well.

Another component of the defense against attacks that target the browser and its add-ons involves regularly applying security updates. Enterprise Management System (EMS) tools can help accomplish this across a large number of computers. Secunia Personal Software Inspector (PSI) is a great free tool to keep up with security patches of a single personal computer.

Individuals can also visit Mozilla’s Plugin Check page to identify which of the installed browser plugins are outdated and might have known vulnerabilities. The page works with Firefox, Chrome and Opera; its support for Internet Explorer is very limited. Users of Google Chrome can also use the Secbrowsing extension to accomplish this.

This note is part of a series that explores attacks that use the web browser. Other posts in this series are:

• Three Web Attack Vectors Using the Browser
• Mitigating Attacks on the User of the Web Browser
• Mitigating Attacks on Web Applications Through the Browser

— Lenny Zeltser

Mitigating Attacks on Web Applications Through the Browser

Applications running on web servers can be attacked in many ways. One of the approaches involves using the web browser of the victim as a gateway for the attack. Such attacks include the following tactics:

• The attacker can trick the victim’s browser into executing malicious browser code, such as JavaScript, in the context of a vulnerable web application. This is an example of a Cross-Site Scripting (XSS) attack.
• The attacker can trick the victim’s browser into visiting a site or clicking on a link that submits a specially-crafted request to the vulnerable web application. This attack category is known as Cross-Site Request Forgery (CSRF).
• The attacker can design a malicious website that embeds the visitor’s desired web application while floating invisible HTML elements above the web app’s genuine user interface. The victim will believe he is interacting with the legitimate site, while the attacker’s code intercepts user input. This type of an attack is known as Clickjacking. (Some classify Clickjacking as a variant of CSRF.)
• The attacker can design a malicious application that runs directly on the victim’s computer and embeds itself into the browser as an add-on or a DLL. This allows the attacker to intercept and tamper with all traffic sent by the browser. An attack of this type is sometimes called man-in-the-browser; its infection vector is similar to that of other local malware.

By channeling attacks through the victim’s browser, the attacker often has the ability to take actions in the context of the victim’s session with the target web application. This allows the attacker to interact with the application under the victim’s privileges.

Many of the vulnerabilities exploited by the attacks outlined above need to be fixed by the developers of the web applications, which aren’t under the direct control of the victims. However browser users can take some mitigation measures.

Modern web browser are starting to include mechanisms for resisting attacks outlined above. For instance, Internet Explorer 8 includes anti-XSS, anti-CSRF and anti-clickjacking features. Google Chrome offers some protective capabilities of this manner as well. Users of Firefox can mitigate the risks of CSRF, XSS and other attack on web applications by using the NoScript extension.

Of course, such browser-based defenses aren’t without weaknesses; case point: the Abusing Internet Explorer 8’s XSS Filters paper by Eduardo Vela Nava and David Lindsay (PDF).

This note is part of a series that explores attacks that use the web browser. Other posts in this series are:

• Three Web Attack Vectors Using the Browser
• Mitigating Attacks on the User of the Web Browser
• Mitigating Attacks on the Web Browser and Add-Ons

— Lenny Zeltser

Mitigating Attacks on the User of the Web Browser

Attacks that target the web browser’s human element—the user—by using social engineering can be very effective. The developers of web browsers are placing greater emphasis on this attack vector. They do this by providing better guidance to the user regarding the risky actions taken by the website.

NSS Labs recently tested browsers’ ability to protect users from socially-engineered malware. According to NSS Labs, Internet Explorer surpassed the effectiveness of other browsers to protect the user from this attack vector.

Internet Explorer achieved such performance as the result of its improved SmartScreen feature, which incorporates application reputation capabilities starting with Internet Explorer 9. This aspect of SmartScreen maintains reputation data about known bad and known good executables. It also warns the user when the executable that he or she is attempting to run doesn’t have reputation data:

Anti-virus tools are starting to include similar capabilities, as you can see in the Norton Internet Security 2011 screen shot below; however, Internet Explorer’s improved SmartScreen feature is the first time I’ve encountered application reputation tracking built directly into the web browser.

Application reputation capabilities of end-point security tools help mitigate some risks associated with the user of the web browser executing a malicious program. Security awareness training is an important aspect of the mitigation strategy as well. So is limiting the privileges that the user has locally and on the network.

This note is part of a series that explores attacks that use the web browser. Other posts in this series are:

• Three Web Attack Vectors Using the Browser
• Mitigating Attacks on Web Applications Through the Browser
• Mitigating Attacks on the Web Browser and Add-Ons

— Lenny Zeltser

Three Web Attack Vectors Using the Browser

Three web attack vectors seem to be responsible for the majority of computer attacks that involve a web browser:

• The attack can incorporate an element of social engineering to persuade the victim to take an action that compromises security. For instance, the victim can supply data to a phishing site or install a program that will turn out to be malicious.
• The attacker can use the browser as a gateway for attacking web applications via techniques such as cross-site scripting (XSS), Cross-Site Request Forgery (CSRF) and Clickjacking.
• The attacker can exploit a vulnerability in the web browser or in local software that the browser can invoke. Such client-side exploits have targeted browser add-ons such as Flash, Adobe Reader and Java Runtime Environment (JRE).

Most attacks include one or two of the three techniques. For instance, Koobface worm targets the user (social engineering to click links) and the web application (hijacking social networking site sessions). An attack that combines all elements would be particularly effective (do you know of any examples?).

The following series of posts explores these three web browser attack vectors in greater detail, discussing how enterprises can protect themselves against such attacks:

• Mitigating Attacks on the User of the Web Browser
• Mitigating Attacks on Web Applications Through the Browser
• Mitigating Attacks on the Web Browser and Add-Ons

— Lenny Zeltser

Deploying Google Chrome in the Enterprise

Google understands that to convince enterprises to adopt Chrome as their web browser, the company needs to make it easy to centrally deploy, upgrade and configure Chrome across a large number of Windows systems. To this end, Google released a number of tools for centrally managing Chrome in an Active Directory environment. Specifically:

• Google Chrome is available as the MSI installer package. This allows enterprises to centrally roll out and update the browser using Group Policy as well as commercial Enterprise Management System (EMS) software.
• Google Chrome’s settings can be centrally managed using Group Policy. Google released ADM policy templates to make it easy for Windows administrator to configure the browser according to enforce the organization’s requirements.
• Google’s Chrome Frame plug-in for Internet Explorer allows enterprises to begin adopting Chrome even while continuing to use Internet Explorer. Moreover, Chrome Frame settings are also configurable through Group Policy.

Google Chrome’s support for Group Policy using ADM policy templates is key to capturing the enterprise market. Administrators can easily add Google’s ADM policy settings to the Group Policy Management Console (GPMC) that they already use to manage the Active Directory environment:

Administrators can then use GPMC to configure the desired Google Chrome settings:

For instance, enterprises can whitelist or blacklist Chrome extensions as part of the effort to lock down the browser’s configuration:

Since the settings are managed using Group Policy, the enterprise can roll them out in a centralized manner across thousands of systems.

The ease with which Internet Explorer can be managed using Active Directory is partly why enterprises have been so loyal to Microsoft’s browser. Mozilla missed this mark, which might contribute to Firefox’s weak market share among large organizations. Google is on the right track to capture the enterprise market with their browser by making it friendly towards environments that make use of Group Policy.

If the topic of managing browsers in an enterprise setting interests you, take a look at the 2-day Combating Malware in the Enterprise course I co-authored with Windows security expert Jason Fossen.

— Lenny Zeltser