Showing posts with label plugins. Show all posts
Showing posts with label plugins. Show all posts

Thursday, May 16, 2013

Fake YouTube page targets Chrome users

Fake YouTube pages are one of the favored ways attackers leverage to get users to click on malicious content. These fake pages often look the same, but the source code can reveal a new twist. This time, a recently encountered fake YouTube page host at http://facebook-java.com targets Google Chrome users only.

Fake YouTube page

We have found a many malicious sites that specifically target Internet Explorer or Firefox users, but not often Google Chrome users. In this example, any click on the fake video player or the fake ad attempts to install the following extension for Google Chrome: https://chrome.google.com/webstore/detail/nhmibhinlbilhaflldckbeokphjoifhi.


JavaScrip code that installs a Chrome extension


You may have noticed that the extension is hosted in the official Google Chrome store. Google disabled the installation of extensions for 3rd party sites in June 2012, and silent installs in late 2012.

The Chrome store page does not show any information about the extension:


Let's install the extension hosted at http://facebook-java.com/.

List of permissions requested by the extension
A new icon is added next to the URL bar:
The link redirects to http://www.getjava.net/. This shows the same page as facebook-java.com. It tries to install another extension from the Chrome store, but this one has already been removed.

getjava.net
Now that the extension has been installed, it is not possible to open Tools or Settings in Chrome. Instead, a tab opens to https://www.facebook.com/?get_cod whenever those functions are accessed. The corresponding code in the malicious extension shows how it is done:

Overrides any tab wit ha URL starting with chrome://
Thereafter, in every webpage viewed four different malicious scripts are inserted. The author uses the Google URL shortener to include the malicious JavaScript:
  • http://goo.gl/9Ky9t => http://profonixcoder.com/yeni/pro.php
  • http://goo.gl/gQhF6 => http://profonixcoder.com/yeni/twitter.php (down)
  • http://goo.gl/t7snI => http://profonixcoder.com/yeni/youtube.php (down)
  • http://goo.gl/jUEgY => http://profonixcoder.com/yeni/askfm.php (down)
Only the first script is available currently. It works on Facebook pages. It shares links using the user's account. By the name of the other files, we can assume they do something similar on YouTube, Twitter and Ask.fm

It looks like the author of this malicious extension doesn't have a high opinion of Google's security by using Google for hosting the extension and using their URL shortener to inject the malicious JavaScript.

Friday, February 22, 2013

The move to plugin-free browsers

Apple was the first major player to offer a browser with no plugins with Safari for iOS. Even the very popular Flash plugin cannot run in the browser. However, no vendor, including Apple, has had such restrictions on their desktop products.

Microsoft has now also gone plugin-free with Internet Explorer 10 Metro. This version of Internet Explorer does not support plugins (except for the embedded Flash plugin which is a allowed on a few whitelisted sites only). See "Get Ready for plugin-free browsing" for additional details.

Chrome and Firefox are also moving in the direction of plugin-free browsers too. The first step is Click to Play, which enables plugins only after an interaction from the user, not by default. With the release of Firefox 19, Mozilla has removed the need to leverage the Adobe Reader plugin by providing a JavaScript based PDF reader. Firefox is also going to enable Click to Play by default (except for Flash) in the next releases.

Blame the plugin vendors

HTML5 is helping browser vendors to get rid of some plugins, like Flash. For example, the standardization around video and sound means Flash is no longer the only option to play a video on modern browsers.

But the main drive toward plugin-free browsers is security.The latest Java vulnerabilities actively exploited and leveraged in successful attacks against Facebook and Apple, are just the latest flaws exposed in Java, Flash and Adobe Reader plugins.

Because these plugins live outside of the browser, they cannot be updated automatically by the browser vendors. Our State of the Web reports continually show that users are slow to update their plugins, even after well publicized vulnerabilities are found.

Not the end of vulnerable browsers

The end of the plugins does not mean the end of vulnerabilities in browser, just fewer of them. This month Microsoft patched about 11 security flaws. But unlike vulnerabilities in plugins which can be exploited in all browsers, browser vulns are specific to each vendor.

Friday, February 8, 2013

HTTPS Everywhere for IE: faster, auto-update enabled

I've released HTTPS Everywhere for Internet Explorer v0.0.0.3. Additional details about the update can be found in the version history of the PDF documentation.

Changes in 0.0.0.3

Faster start up

The start up time is now much faster. You should no longer receive a popup from Internet Explorer asking you to disable certain add-ons. I also switched to a different XML parser to load the HTTPS Everywhere rules.
new load time is well below the 0.20s threshold

Support for custom rules

You can now also add your own rules in custom.ruleset. Read the PDF documentation (page 5) to learn how to use your own SSL rules in Internet Explorer.

Auto-Update

I have enabled the "auto-update" feature. Whenever a newer version of HTTPS Everywhere is available, a new tab will be opened to https://www.zscaler.com/httpseverywhere_ie.php and you can download the latest version from this page. The installer has been modified to update your previous version. Auto-update works for all previous version of HTTPS Everywhere for Internet Explorer as well.


Friday, February 1, 2013

HTTPS Everywhere for Internet Explorer: source code and new version available

I have released the source code for HTTPS Everywhere for Internet Explorer on GitHub as promised in the last blog post. You need Visual Studio Profession 2010 to compile the project and NSIS to build the installer. Feel free to submit patches and open issues directly via GitHub.

If you missed  the previous post, we have ported the browser extension HTTPS Everywhere (Firefox and Chrome, offered by the EFF) to Internet Explorer. This extension makes it easy to access websites over HTTPS whenever possible for better security.

Documentation

In the initial announcement of HTTPS Everywhere for Internet Explorer, I forgot to provide a link to the extensive documentation which describes, among other things, the plugin architectures and how to debug potential issues. You can see how the extension bypasses the limitations of the very weak plugin architecture of Internet Explorer in order to intercept and modify all HTTP and HTTPS requests.

Version 0.0.0.2

A new version is available, you can download it here. I have added the 3,000+ rules from HTTPS Everywhere 3.0 for Firefox (from the EFF). There is also a workaround for Wikipedia.org (issue reported by a user).

Download HTTPS Everywhere 0.0.0.2 for Internet Explorer

Monday, December 17, 2012

HTTPS Everywhere for Internet Explorer

We have previously released a number of browser security extensions to protect users against new threats and security issues, which we did not feel were addressed by anything previously available. Now I've focused my attention on a popular and useful security extension which has been missing on Internet Explorer. Internet Explorer is still the most popular browser in the enterprise, but its weak extension architecture makes it a rather difficult platform to work with. The first extension I wanted to offer to Internet Explorer users is HTTPS Everywhere from the Electronic Frontier Foundation.

HTTPS Everywhere

You can get a detailed explanation of the original extension on the EFF website. In summary, the extension forces a browser to use HTTPS (encrypted HTTP) whenever possible (e.g. when the website allows it).

HTTPS Everywhere redirects users to HTTPS URLs based on a set of rules. Switching from HTTP to HTTPS is still not as easy as it should be and many domains have not designed their websites to be accessed securely. I've explained some of the challenges in an earlier post.

The HTTPS Everywhere rules define which domain name can be accessed over HTTPS and how URLs need to be translated. For example, http://www.google.com/ should be translated into https://encrypted.google.com/. Some sections of websites may not be available over HTTPS and the rules take care of these exceptions.

Example of HTTPS Everywhere rules

HTTPS Everywhere also secures cookies according to rules, adding the secure attribute to cookies sent by the server. This ensures that any later access to the domains using HTTP (unsecure) will not leak sensitive information such as the session ID.

HTTPS Everywhere for Internet Explorer

I'm very pleased to announce the release of HTTPS Everywhere for Internet Explorer 0.0.0.1. You can download it now at https://www.zscaler.com/research/plugins/ie/https-everywhere/https-everywhere.exe.

Early release

As the version number suggests, this is a very early release. I have been using the extension for several weeks without any problems, but it should be considered an alpha release. Version 0.0.0.1 translates URLs from HTTP to HTTPS according to the EFF rules and secures cookies. It does not currently support HSTS, not does it provide support for custom rules.

Requirements

The good news is that the extension works with pretty much all recent 32-bit versions of Internet Explorer:
  • Windows XP SP3 to Windows 8
  • Internet Explorer 6 to 10
The extension will be available for Internet Explorer 64-bit soon. It does not work with Internet Explorer 10 Metro - see this post for more details on the Metro version).


Install it

The extension comes with an installer. Simply download https-everywhere.exe and run it. Then make sure you restart Internet Explorer to enable the extension.

HTTPS Everywhere installer

Documentation

We have a detailed documentation available on our website. It details how the extension works and describes it's architecture. Some of the behaviors are not obvious, so I strongly suggest that you read it. The documentation will be updated as we release new versions of HTTPS Everywhere for Internet Explorer.

Next

This is a very first release of HTTPS Everywhere and there will be many more to come. The first task on my todo list is to make the source code available on the EFF website. Then I'll add the features missing from the Firefox and Chrome versions, including HSTS support, custom rules, etc.

You can check the HTTPS Everywhere for Internet explorer page on the Zscaler website for updates.

Friday, December 7, 2012

Flash in Windows 8: the good, the bad and the ugly

Last week I described how Chrome and Firefox are protecting users against vulnerable plugins, Flash and Java amongst them, with Click to Play. Microsoft has a different approach with Windows 8 when it comes to protecting users against attack using the Flash plugin.

Embedded Flash Player

Windows 8 ships with its own version of Flash. Users can no longer install Flash from the Adobe website. On the good side, Flash updates are now part of the overall Windows update process.

This is similar to Apple shipping their own version of Java. While it forces users to update their plugins along with the OS, we've also see the downside. MacOSX was hit by malware that used a vulnerability in the older Java version shipped by Apple that had been patched months prior by Oracle.

Microsoft and Adobe have a much closer relationship than Apple and Oracle, but the Flash version shipped by Windows 8 (11.3.376.12) is already quite far behind the latest version offered by Adobe (11.5.502.110). The same problem that Apple faced with keeping up with security upgrades might already be occurring in Windows 8.

Flash version number in Windows 8 at the top

Internet Explorer Desktop and Internet Explorer Metro

Windows 8 comes with two version of Internet Explorer 10: the Desktop version and the Metro Version.

Internet Explorer 10 Metro


The Desktop version is pretty much the same as Internet Explorer 9 on Windows 7. Besides the embedded Flash version, Flash content is handled the same way as it is in Internet Explorer 9.

The Metro version, besides a very different UI, handles Flash very differently. Microsoft has decided to let the Flash plugin run only on a list of whitelisted websites. For all other websites, Flash is disabled. This is a more intrusive protection than Click for Play, but it also brings better protection.

Flash disabled on non-whitelisted website
However, I must say this behavior is quite disconcerting to the user. There is no warning from the browser that Flash has been disabled for a given website, but not for others. Most websites, like the one above, will just say that Flash is not installed, and give a link to the official Adobe website .... which the Windows 8 user cannot use!

The only work around for webmasters to enable Flash on their website is to ask users to switch to the Desktop version of Internet Explorer. Webmaster can add an HTML tag or HTTP header to request the user to switch versions. Internet Explorer Metro shows a popup suggesting a switch to the Desktop version.

No plugin

The other plugins (Java and others) work fine on the Desktop version, but not at all on the Metro version. No warning is shown to the user. Browser extensions (BHO, Browser Helper Object) are also not working with Internet Explorer Metro.

Microsoft is taking a radical approach by forbidding plugins and extensions to run in the Metro version of Internet Explorer. We will see if users switch back to the plugin-enabled Desktop version, or if webmasters will move to HTML5 to replace their Flash and Java content.

Thursday, November 29, 2012

Click to Play: the next step for Firefox

Click to Play first appeared in Firefox 14 and it appeared in developer versions of Chrome back in 2010. I described the feature in a post last July. Click to Play disables all plugins by default on all pages. The user then has to explicitly click on a warning to let the plugin, Flash or Java for example, run. Chrome and Firefox both have Click to Play disabled by default. After trying to use Click to Play for a week in Firefox, I had to give up, too many websites were not working and the warning was not always showing on the page.

Click to Play warning in Firefox 14


Firefox 17

Firefox 17 is the first browser to enable Click to Play by default, with a caveat. Click to Play is enabled only for plugins that are outdated and vulnerable. It is possible to enable Click to Play for all plugins, including up to date ones, by changing the property plugins.click_to_play to true in about:config. However, it is not possible to disable the feature for vulnerable plugins.

One of the problems in the previous implementation of Click to Play was that plugins could be used without any visual widget on the page, so no warning would be displayed to the user. In Firefox 17, there is an additional icon on the left of the URL bar that is visible when a plugin has been disabled on the page. You can click on the blue icon to choose what to do: enable the plugin once, always enable the plugin on the site, etc.

New icon to manage disabled plugins

More options for always disable or enable outdated plugins on a site

Plugin check

Firefox has also had tools to verify whether the plugins installed are up to date for a while. However, this is a manual process: go to Tools - Add-ons - Plugins and click on Check to see if your plugins are up to date. This opens a new tab to the Firefox website with information about the plugins installed.

Information about my plugins

You will notice that four of my plugins are unknown to Mozilla. In this case, the page cannot tell me whether they are up to date or not.

Fortunately, Mozilla makes it clear when there's a difference between outdated versionssimply lacking new features and unsafe versions:

Vulnerable Flash version

Outdated Flash version
Click to Play kicks in for vulnerable versions only, not for outdated versions of a plugin. This is better for companies that don't let users upgrade to the latest version (like Flash 11) but still install safe versions of older releases (Flash 9 in my example).


Not full security

First, Mozilla cannot manage all plugins. It is not always able to tell whether a particular version is safe or not. Because Mozilla chooses to enable Click to Play for outdated and vulnerable version only, it would not have protected users against 0-day vulnerabilities, like the vulnerability that affected the latest version of the Java plugins, or the Flash 0-day exploit that circulated on the web.

Strangely, the feature stopped working for me after a while. I reinstalled Firefox, wiping out all my user settings, a couple of times, but the same thing happened: after using Firefox for about one hour, Click to Play was not kicking in anymore.

While it is not a silver bullet, this is a good step forward in making Firefox user safer. They have also made UI improvements since Firefox 14 that make the feature much more usable.

Tuesday, September 25, 2012

How to install silently malicious extensions for Firefox

Recently, I had the pleasure of presenting on malicious browser extensions at SOURCE Seattle. I showed, amongst other things, how a malicious browser extension can be added silently to any Firefox profile. I've reworked the demonstration, and want to make it available to a wider audience.

3rd-party installation

You have probably already have encountered applications, like the Flash player or some repackaged free software, that wants you to install a toolbar or some spyware/adware for your browser. This is a 3rd-party installation of an extensions. For Firefox, this installation consists of copying the browser extension into your Firefox profile (or a special folder that contains extensions shared by all profiles).

Software installer contains a toolbar/adware/spyware extension

Firefox protects against this type of external extension installation by prompting the user the next time the browser is started - the user has the option to disable (default action) or enable the new extension.

Firefox warning for an extension installed outside of the browser

Silent installation

It is actually very easy to bypass the warning from Firefox. Firefox stores information about all extensions in a Sqlite3 database named extensions.sqlite, located in each Firefox profile. It contains:
  • name, version, description, etc.
  • enabled or disabled
  • active or not
  • installed from official Mozilla extension site or not
extensions.sqlite

When Firefox starts, it checks the list of extensions under /extensions/ against the content of extensions.sqlite. If an extension exists on disk, but is not listed in the database, a warning is shown. The trick to install an extension silentlt, is to add a record into the database about the extension being installed and tell Firefox that the extension has actually already been approved by the user (active and enabled).

Demonstration

I've written a small program that installs an extension silently into any Firefox profile. You can download the program and the extension here, and the source code there.

The program was written in C# and can be compiled with the free Visual Studio Express for .Net from Microsoft.

Tool shows the steps to install the extension silently

The "malicious" extension does not actually do anything. All the malicious code has been commented out, although it includes some of the things an attacker could do, such as:
  • steal the list of logins and passwords saved
  • send out all the URLs visited by the user
  • disable security features
Do not worry about testing the "malicious" finctionality, the extension will not do anything - no information will be sent out.

I suggest that you create a custom profile to test the extension. To create a new profile named "demo", run the following command:

firefox -CreateProfile demo --no-remote

Then start Firefox with your new profile:

firefox -P demo --no-remote

I've included a video that shows the silent installation in case you're fearful of trying it for yourself:


Why it matters

Many free software packages push toolbars, adware and spyware into Firefox and other browsers, installed as part of their installation to earn some money for the extension creator (see previous PPI campaigns). Firefox gives users a chance to explicitly and clearly decide whether or not they want to enable these add-ons. Without this protection, many users can be tricked into running extensions they were are not aware of.

The second important point is that malicious browser extensions are much harder to detect once installed. Because extensions are part of the browser, their activity cannot be differentiated from the activity of the browser. Accessing the internet and accessing the file system are legitimate actions for the browser. The extension does not need to add itself to the startup scripts, or as a Windows service to be running after a computer reboot. The extension does not need to hook into Windows to intercept logins and passwords, etc. Finally, AV vendors struggle with detecting malicious JavaScript and any of the malicious Firefox extensions I've checked with VirusTotal were never flagged.


Going further

The silent installation could be even more sneaky. Instead of adding a new extension, it could also replace an existing extension, or append itself to an existing extension.

Thursday, August 16, 2012

Zscaler Safe Shopping 1.1 for Internet Explorer: C++ BHO

I released Zscaler Safe Shopping for Internet Explorer in March 2012. This was my first attempt at writing a Browser Helper Object (BHO) and it was written in C#. There are are number of disadvantages to using C#, as I described in my last post. C++ is required for "advanced" features, like intercepting and modifying all HTTP/HTTPS traffic.

Ultimately, I decided to bite the bullet and to learn C++ on Windows in order to deliver some great extensions for Internet Explorer this year. It was quite a steep learning curve to go from from C# and the scripting languages (Perl, Ruby, etc.) that I knew well, to C++. CodeProject turned out to be a great source of sample code for C++ BHOs. Various colleagues also helped to shorten my learning curve. Now here were are and Zscaler Safe Shopping has been rewritten from scratch in C++. If you are using version 1.0, an upgrade to the new 1.1 will speed up your browsing when the extension is in use. C# BHOs require that the .Net framework be loaded first, which takes at least 0.20s-0.30s for every tab. With C++, load time is significantly reduced.

It is very important that the BHO loads quickly, in under about 0.20s so as to not negatively impact the user experience and avoid warning messages. Starting with Internet Explorer 9.0, a warning is shown to the user when the browser opens to disable "slow" add-ons:
Warning about slow add-ons

It is much harder to write browser add-ons for IE than it is for Firefox and Chrome, but you can do quite a lot with IE. Here is the breakdown of the "advanced" features available to add-ons on the three major browsers:

Feature Firefox Internet Explorer Chrome
Modify HTTP requests and responses YES YES YES
Access the file system YES YES NO
Include C++ libraries YES YES* NO
Run executables YES YES NO
Run server inside browser YES YES NO
(* IE add-ons are C++ libraries, of course)

I plan on releasing some exiting browser add-ons for Internet Explorer this year, keep an eye on this blog!

Friday, July 20, 2012

"Click to Play" arrives in Firefox

Popular browser plugins like Flash and Adobe Reader are part of the typical web browser, with an installation base of 90+% on corporate computers (see the State of the Web report). However, they can also represent big security holes. The Blackhole exploit kit, for example, has long contained code to exploit vulnerabilities in Flash, Java and Adobe Reader. While few people may actually need a Java plugin, Flash is still required on many websites and a PDF reader in the browser is quite convenient.

Click to Play

Browser vendors have been looking for ways to secure browser plugins. One way to achieve this involves sandboxing the plugins, i.e. running plugins in a more restricted environment than the browser, with fewer rights. Unfortunately, many exploits have demonstrated that it is all too often possible to break out of the sandbox.

Another idea involves disabling plugins by default and enabling them only when they are actually required by the user. "Click to Play" means that users must take action to enable a plugin by clicking on the area of the page that is handled by a plugin, like a Flash animation.

The vast majority of exploits, including Blackhole, use invisible elements to run the malicious code: an invisible applet, invisible Flash animation, etc. Since Click to Play requires the user to actually notice elements on he page that require a plugin in order to activate it, these exploits would not run.

Click to Play in Firefox - 2 clicks are required to enable the 2 Flash animations

Some inconveniences

Click to Play seems like a great security improvement. Unfortunately, there are legitimate cases when a plugin might be required to run without having to display anything. For example, Flash is commonly used to copy text to the clipboard (a shortened URL, for example).

There are also JavaScript frameworks that use invisible Flash or Java applets to get access to the webcam or microphone (this is not possible through JavaScript only).

There also UX challenges when asking users to click YouTube videos over and over, for example, or to ensure that users understand why they may not want to enable all plugins by default, etc.

Today, only two major web browsers support Click to Play - Chrome and Firefox, but this feature is disabled by default in both browsers.

Chrome

Click to Play was introduced as an option in Google Chrome in March 2011 with Chrome 10. Because it is disabled by default and Chrome rarely requires users to navigate through the settings to enable it, most users are likely not aware of this security feature.

In the latest versions of Chrome, Click to Play is well hidden! To enable it one must go to the Wrench Icon - Settings - Show advanced settings - Content settings...then scroll down to Plug-ins and select "Click to Play". That's five clicks to access the option. This is definitely restricted to power users! If you do not know what "Click to Play" means, you are out of luck because there is no mouse-over or popup to show more information.

Click to Play option in Chrome 20

While the screenshot of Chrome 10 showed placeholders explaining that users had to click to enable the plugin, the current placeholder are quite obscure, with no information about what they are.

Click to Play placeholders - What should I do?

It looks like the Click to Play feature is pretty much dead in Chrome, restricted only to power users. Not much has happened since it was released over a year ago.


Firefox 14

Finally, a year after Chrome, Click to Play is making it first appearance in Firefox 14. Like Chrome, it is disabled by default, and restricted to power users. There is no UI option to enable the feature. You have to go to about:config, search for click_to_play, and change the option to true.

Enable Click to Play in Firefox 14

Firefox's placeholders are better than Chrome's, as they clearly state "Click here to activate plugin". I wish however that they would indicate which plugin is going to be activated (Flash versus Java, for example).

Click to Play placeholders in Firefox

I'm afraid that the current implementation does not play well with Flash embedded in an IFRAME. On  a website that embeds a YouTube video, I get a black box, with no option to enable Flash to see the video.

To Mozilla's credit, this is just the first iteration of Click to Play. Full support for Click to Play is scheduled for Firefox 16. Looking at their website, they seem to have a good plan to tackle the UX issues.


I hope Mozilla and Google are working on making Click to Play the default setting. This would result in a big improvement in securing users online. Right now, only a few users are aware of it and even fewer benefit from the added security.

Monday, April 30, 2012

Search Engine Security for Internet Explorer

Search Engine Security (SES), a browser extension designed to protect users against Blackhat SEO links in search engines, is now available for Internet Explorer. You can download it from our website. It is compatible with Internet Explorer 6.0 and above, on Windows XP thru Windows 7.

The features are the same as Search Engine Security for Google Chrome, released two weeks ago. The Referer and the User-Agent headers are modified when you follow a search result link on Google, Bing and Yahoo! This prevents the hijacked sites from redirecting users to a malicious page.

As with SES for Firefox and Google Chrome, you can turn the extension on and off for the three search engines.

Search Engine Security enabled on Bing

You can also whitelist specific pages. The only difference with the IE version as opposed to Firefox and Chrome is that the Referrer cannot be empty. This is why the default value is "-".

The options are available under Tools > Search Engine Security options.

Search Engine Security options

To test the features, search for "what is my user agent" or "what is my referrer" in Google, Bing or Yahoo! and follow a link. You will notice a different value when Search Engine Security is ON or OFF.

Modified User-Agent
There are very few browser extensions available for Internet Explorer, especially extensions helping to keep users safe. I will continue to port the Zscaler security extensions to Internet Explorer and will bring other security tools to this platform.

You can find a full list of all our browser extensions on the ThreatLabZ portal under Tools. Search Engine Security for Internet Explorer can be downloaded here.

Monday, April 16, 2012

Search Engine Security for Google Chrome

Google Chrome has recently added an API to modify HTTP headers. This in turns, made it possible to port Zscaler's Search Engine Security add-on from Firefox and Firefox Mobile to Google Chrome.

Search Engine Security on the Chrome Web Store

Most hijacked websites used for Blackhat SEO check the Referer header and the User-Agent, to decide whether to redirect the visitor to a harmless spam page or to a malicious domain (Fake AV page, Blackhole exploit kit, etc.). By modifying these 2 headers when the user leaves a Google, Bing or Yahoo! search, Search Engine Security fools the hijacked site into thinking that the visitor is not a real user and therefore avoids redirection to the malicious content.

Search Engine Security enabled for Google

All the work is done in the background, so it can be tricky to understand exactly what happens, or even if the add-on is working. We have therefore added a small note on the Google/Bing/Yahoo! search result pages to show you whether Search Engine Security is on (default settings) or off (disabled in the options):  Zscaler SES on or Zscaler SES off.

Search Engine Security disabled on Bing

To understand how the the headers are modified, look for "referer mobilefish" in Google after you have installed Search Engine Security. Click on the first link "Mobilefish.com - Show my IP". The page will display your User-Agent string and Referer header. With the default settings, the string "slurp" is appended to your User-Agent, and the Referer header is removed. These changes are done only when leaving a Google/Bing/Yahoo! search page.

You can also enable/disable the various settings on the Search Engine Security options page to see how the User-Agent and Referer strings are affected.

Search Engine Security options

You can install Search Engine Security for Google Chrome in the Chrome Web Store.

Tuesday, March 27, 2012

My experience wirting an add-on for Internet Explorer

I've released my first add-on for Internet Explorer and I've almost finished a second one. Developing for Internet Explorer was a very different experience than developing for the other browsers I've worked with before - Firefox, Firefox Mobile, Google Chrome, Safari and Opera.

Overall Architecture

Internet Explorer extensions are called Browser Helper Objects (BHO). They are libraries (DLL) implementing a specific interface. They must be registered as a BHO through a registry key in order to be used by Internet Explorer.

The BHO is loaded per tab or window, meaning there is no built-in communication between tabs/windows. BHOs can interact with the browser and the document through native code or injected JavaScript.

BHOs can be written in C++, C# or VB.Net. Since I'm most familiar with C#, this is the language I've used. Unfortunately, there are many limitations with .Net based BHOs:
  • The BHO name, displayed in the Internet Explorer "Manage Add-on" page, displays the namespace of the application. I could not therefore display "Zscaler Safe Shopping", so I had to cheat and use Zscaler as the namespace, and SafeShopping as the main class name to display "Zscaler.SafeShopping". (see DUcer's comment below)
  • Many important functions are not implemented in C# and unmanaged C++ code has to be imported.
  • Internet Explorer is very picky about performance - if an add-on takes more then 0.20 seconds to load, IE suggests to users that they disable the plugin (see more details below). Due to the fact that .Net add-ons require IE to load the .Net framework, it is pretty much impossible to stay below this limit.
Because the extensions are comprised of compiled code, I could not download extensions to check out their source code as examples, unlike extensions for other browsers, which are written in JavaScript. In addition, Microsoft has only high-level documentation about BHOs and very few code examples (with most leveraging C++).

Protected mode

Starting with Windows Vista and Internet Explorer 7, Internet Explorer works in Protected Mode by default. This means BHOs are limited in the places they can read/write to disk and read/write to the registry. You need to call special functions to know where you are allowed to write to the disk, but these functions are available in C++ only. I had to use a mix of hardcoded values and unmanaged C++ DLL import to add all necessary functionality.

Because there are no built-in debugging functions to understand what is going on inside the extension, and limited documentation from Microsoft, it took me quite a while to understand how to deal with Protected Mode.

Inconsistent environments

On other platforms, extensions are relatively compatible between browser versions and operating systems. With Firefox extensions, for example, it doesn't matter if the browser is running on Linux, Windows 95 or Mac OS X. These browsers are also very good at maintaining forward compatibility: extensions working on one version usually work fine on newer versions of the same browser. Internet Explorer is a different beast.

Some of the API belongs to the Windows OS, while other portions belong to Internet Explorer. For example, Protected Mode exists on IE 7 on Windows Vista, but not on Windows XP. The API to manage disk access is also different on the two OSs. Calling Windows Vista's API will crash Internet Explorer on Windows XP, for example. Add-ons are definitely not forward compatible.

Some API calls also get "randomly" broken. For example, the event BeforeNavigate2 is broken on Windows 7. This was reported during for Release Candidates, but never fixed and the event is not triggered anymore.

No love for extensions

Microsoft does not seem to have much love for browser extensions. In fact, I think they actually hate them!

There is no good website to download IE extensions. The official Microsoft website, Internet Explorer Gallery, contains very few extensions. Add-ons are not even shown on the front page, instead they promote pinned sites (introduced with IE 9)

Developers don't get much love either. In addition to the problems and limitations listed above, the add-on infrastructure in Internet Explorer is very weak. Developers have to write their own installer to install and register their BHOs. They also have to write the uninstaller, as IE lets users disabled BHOs, but not uninstall them. There is no simple way of adding an option page for to configure the extension either.

If this was not enough to discourage add-on developers, IE regularly asks users whether they want to uninstall add-ons. Even if all add-ons are loading under 0.200 seconds, Internet Explorer still suggests that the add-ons be disabled to improve the start up time!

A Bad Reputation

BHO is a dirty word. If you look for BHO in Google, most search results are about how to remove malware installed as a BHO.

Users are also more wary, as they should be, of downloading executables that must be executed outside of their browser, and require Admin rights to register themselves, as opposed to Firefox .xpi files, which are handled entirely inside the browser.

References

If I have not yet discouraged you to write a .Net BHO, here are a couple of references I used:

Monday, March 19, 2012

Zscaler Safe Shopping for Internet Explorer

Zscaler Safe Shopping, the browser extension that warns users when they visit a fake store or compromised store, was Firefox, Google Chrome, Safari and Opera. It is now available for Internet Explorer 6 to 9 (Windows XP, Vista and 7). This is the first extension we released for Internet Explorer, and hopefully not the last one. You can download it here.

Zscaler Safe Shopping warning in Internet Explorer

Fake stores are still prevalent in Google searches for buying software online. If you get redirected to one of the fake store, a banner will be displayed at the top of the page to let you know the the website is not safe. We update the blacklist of fake and compromised stores regularly.


Browser Helper Object

Internet Explorer extensions are called Browser Helper Object (BHO). Unlike all the other major browsers, the add-on infrastructure in Internet Explorer is very incomplete. Internet Explorer does not offer a way to easily install add-ons, to update them, or to configure them. Instead, add-ons are treated as regular Windows program. Zscaler Safe Shopping comes in the form of executable to install and register the BHO. You can disable add-ons from within Internet Explorer, but you have to use the Control Panel to remove them completely from your system.

Zscaler Safe Shopping installer

Zscaler Safe Shopping installed


The executable required administration rights to register itself as an Internet Explorer add-on by modifying the registry. Although the add-on appears in Internet Explorer right after the installation, a restart of Internet Explorer is required to activate the plugin.

You can download Zscaler Safe Shopping from our website.

I will talk more about developing BHO in later posts.

Wednesday, January 25, 2012

Fake missing plugin warnings used for spam/spyware

A key element for a successful spam/malicious page is to establish trust with the visitor so that he will perform the requested actions. Users trust their browser, but not necessarily the content (i.e. web page) that it displays. A trick that I've blogged about earlier, is to fool the user into thinking that certain elements on the page are actually from the browser.

Recently, I've seen several websites showing a fake warning for a missing plugin. The fake warning is designed to look the same as the real warning shown by Firefox when the page requires a plugin that is not installed: a yellow bar at the top of the page with a link to install the plugin on the right, and a blue icon on the left.

Legitimate Firefox warning for a missing Adobe Shockwave plugin

On allostreaming.biz (French language), the fake warning is for a "missing" VLC plugin. You can tell that the warning is part of the page, and not part of the browser, because the scroll bar goes to the top of the warning, whereas the real warning is above the scroll bar (see the image above).

Fake warning for missing plugin
A look at the source code shows that the warning is indeed HTML from the page:

HTML code for the fake warning
The "VLC plugin" is the classic pay-per-install bundle, where the spammer gets paid for tricking the users into installing spyware/adware.

The spammers are using the same fake warning on all browsers, which is also a giveaway as browsers other than Firefox don't actually have the same warning for missing plugins. Anyway, the attack will likely fool users of other browsers into installing this adware/spyware.