Friday, February 25, 2011

Zscaler Safe Shopping - Stay protected against compromised or fake stores online

Install Zscaler Safe Shopping add-on for Firefox 3.x

We're happy to release yet another free Firefox plugin to protect consumers online.

Introducing Zscaler Safe Shopping

This product has been submitted to the official Mozilla Add-ons sites, but will likely take a few weeks to be approved. In the meantime, you can download it from our site.

Zscaler Safe Shopping Add-on Installed

Why do you need Zscaler Safe Shopping?

Virtually all browsers contain blacklists to prevent users from accessing malicious sites: Google Safe Browsing, Phishtank, etc. These blacklists do not however, generally block sites that have been compromised by Blackhat spam SEO attacks, HTML/JavaScript injections that pull malicious content from another domain. Rather, they block the malicious pages that hijacked sites redirect you to - or pull content from.

While this is fine for most websites, assuming you simply surf and do not input any sensitive information anywhere, but would you be okay with giving your personal mailing address, phone numbers and  credit card information to a website that is fully controlled by ill-intentioned hackers? The problem is, how do you know whether the sites you are visiting have not been compromised or not when your tools ignore these types of threat?

Zscaler Safe Shopping is continually up-to-date, via the Zscaler cloud security service, on compromised and fake online stores. It warns users when they visit one of the suspect domains.

Install Zscaler Safe Shopping add-on for Firefox 3.x

Compromised stores

A compromised store is an e-commerce website where one or several groups of hackers has full access and can add/remove/modify pages, access the database, etc. This means they can change an order form to get all shopper information, or get data directly from the store's database;  they can even change a payment form and redirect you to a a phishing site.

Zscaler detects compromised online stores based on several factors that demonstrate total control by an outside party by becoming aware of:
For regular users , these sites may not show any sign of being hijacked, - and that's exactly what the attackers want.

To see a sample warning of a compromised store, go to after you install the plugin.

Zscaler Safe Shopping Warning - Compromised store

To prevent people from using our list to find compromised sites for malicious purposes, we store the domains as a hash table, rather than as plain text list.

Fake stores

Recently, we highlighted the number of high profile, legitimate sites, that have been hijacked to lead to fake online stores. These stores offer up software downloads at highly discounted prices. The downloads are not blocked as malware by Google Safe Browsing, or as phishing sites by Phishtank.

We've found approximately 100 such fake stores. Those numbers are still high, with more are coming every day.

Fake Online Store

To see the warning for a fake store, go to after you install the plugin.

Zscaler Safe Shopping Warning - Fake Stores

Zscaler Safe Shopping Options

You can customize Zscaler Safe Shopping via the following options:
  • Whitelist: do not show a warning for a list of user supplied domains
  • Blacklist download interval: how often should the plugin download the new list of compromised and fake stores

Zscaler Safe Shopping Preferences

In addition to the option menu, Zscaler Safe Shopping adds an icon to the status bar, at the bottom of the browser. This allows you to turn the plugin on and off with a click of the mouse, without having to restart Firefox. The icon becomes gray when the plugin is disabled.

Zscaler Safe Shopping Status Bar

We'll release updates to Zscaler Safe Shopping in the coming days and weeks as we get feedback from users. Don't hesitate to report any problems or submit question as a comment to this blog, or contact me directly at This plugin is a nice addition to our Search Engine Security (SES) add-on to keep consumers safer online.

Install Zscaler Safe Shopping add-on for Firefox 3.x

Shop Safely!

-- Julien

Thursday, February 24, 2011

Facebook phishing pages

On 02/13/2011, I found several domains used for Facebook phishing, registered the same day:
These domains contain the same page: a simple form to enter a Facebook login and password.

Facebook Phishing page

After entering the credentials, users are redirected to!/album.php?profile=1&id=208421665712, which lands the user at their Profile Pictures page. If the user was not yet logged into Facebook, he must login "again". The phishing page does not post the credentials to Facebook on the user's behalf.

Fast-flux DNS

All of the domains were registered by the same individual in China.

WHOIS information for

The domains are bound to multiple IP addresses that change rapidly (aka fast-flux DNS):
DNS information for
They all use the DNS server, which has been used for other Facebook phishing sites in the past.

Random redirections

On 02/14/2011, these 6 domains where redirecting users to in the morning. In the afternoon, they redirected users to On 02/16/2011, they seem to display the phishing pages all the time. I'm not sure why these redirections were set up earlier.

These domains are not yet blocked by Google Safe Browsing.

-- Julien

    ICWAI site infected

    After KVGBANK, now ICWAI has also been found to be the victim of an iFrame injection attack. My previous blog post reveals how famous sites from India like UPSC and KVGBANK have been compromised. These are reputable sites , which receive a high volume of traffic. This makes them an attractive target for attackers. The ultimate motivation of the attackers is to leverage the sites as a catalyst for spreading malware.

    The ICWAI webpage was found to be infected with a malicious 0 pixel iFrame. Injecting iFrames into legitimate websites has become an extremely common attack vector.

    Screen-shot of the affected page:

    Screen-shot of the source code :

    The injected link no longer serves malware as the domain has been taken offline. The fact that the ICWAI page still contains the injected iFrame suggests that the injection vulnerability that led to the attack, may still be exposed and could lead to additional infections. Zscaler has informed ICWAI of this infection.

    Screen-shot of hxxp://, the injected URL:

    Fortunately, this domain has been added to the Google Safe Browsing block list. Online searches reveal information providing a clear indication that the “” domain has been used in various malware campaigns. A report from ThreatExpert shows that some of the links on this domain have been used to serve a known Trojan.

    This is yet another example of the poor level of web application security, which is allowing attackers to infect legitimate, web sites with minimal effort.


    Sunday, February 13, 2011

    KVGBANK Affected with Malicious JavaScript

    Karanataka Vikas Grameena Bank is victim of an attack. The site is comprised by the injection of malicious obfuscated JavaScript.

    Home page of :

    Obfuscated JavaScript :

    Multilevel obfuscated JavaScript was used to infect the site. Ultimately, it required two levels of De-obfuscation to fully decode it.

    Part of De-obfuscated JavaScript:

    The purpose of such attacks is to redirect the victims browser to pull content from a malicious site. Attackers have learned that it is far more effective to simply infect already popular websites, rather than set up a separate malicious site and social engineer victims into visiting it. In this particular instance, the De-obfuscated code opens a pop-up box depending on user's browser version. The link used now points to a parked domain but likely previously hosted malicious code.

    Home Page of :

    Even though the malicious code is not delivered by above site, it is possible that the vulnerability that led to the attack has not yet been patched and further infection could occur, or in future the linked site may host malicious content. We have informed the bank about the infection.

    Virustotal results shows 23 out of 43 AV's vendors trigger on the kvg bank site.


    Friday, February 11, 2011

    Blackhole exploits kit attack growing

    Recently, we have seen an increase in Blackhole exploit kit attacks. Blackhole is yet another web exploit kit developed by Russian hackers. According to one forum, the author indicates that the kit will cost $1,500 annually, $1,000 for a half-year and $700 for 3 months. It is a very powerful kit with a number of recent exploits including Java and Adobe PDF exploits. The attacker has continually improved the kit with more obfuscation and crypto algorithms to avoid the detection by AV vendors. One of the lines from description of the kit says it all - “Exploits crypt on special algorithms that make it impossible to code analysis and detection of anti-virus as well as services,Tipo wepawet and other counterparts ...”. Analysis of this malicious toolkit showed that URL patterns remain the same for most of the malicious domains hosting the Blackhole exploit kit. A Google search for the URL patterns returns thousands of results for such domains and Google does generally flag them as malicious domains. Here is the screenshot of Google search:

    The exploit kit sends heavily obfuscated JavaScript code with Java applet code, which will download a malicious JAR file to the system. Here is what the code looks like:

    The above JavaScript code is formatted for better viewing. It is heavily obfuscated to avoid antivirus detection. If we decode the content, we see that the kit is targeting a recent vulnerability in Java. The VirusTotal result for above “.jar” file is very poor with only 2 antivirus engines triggering on it. Here is the decoded part of the script,

    The above decoded JavaScript targets CVE-2009-1671. It will download a malicious binary called “info.exe” from the server and execute it on the system. The VirusTotal result for this file remains poor at only 47%. There is also another Iframe attack in the decoded JavaScript code.

    The above code will append the malicious Iframe to the body of the webpage, which points to another malicious URL. The above malicious URL contains yet another malicious URL in an ASX file format. This is intentionally done to avoid a user prompt. Here is the source,

    This URL then sends more obfuscated JavaScript code exactly like the second image of the blog. Once decoded it shows JavaScript code which targets CVE-2010-1885. Here is the decoded script,

    We have seen many similar web exploits kits in the past and attackers are coming up with new ones like Blackhole with more features and reliable and undetectable exploits all the time. We are also seeing large number of malicious domains hosting Blackhole exploits kit. The detection ratio is generally very poor for malicious binaries contained in the kits. Even though the price of this exploit kit is high, it remains a sought after commodity.


    In depth analysis - decoding HTML Style tag based malicious Iframes

    Injecting clear text or obfuscated malicious Iframes has become a common attack vector. By taking advantage of known/unknown vulnerabilities in web servers or applications, an attacker can inject a malicious Iframe which will point to a malicious domain hosting malware. Attackers continually modify the way they inject malicious Iframes, leveraging various encoding techniques, to hide their malicious code from security products. They also do this to add complexity for security researchers trying to decode the attacks in the first place. Recently, we came across another malicious Iframe attack which was carried out with the help of HTML style tags. Here is the screenshot of an attack found on an infected website:

    Attackers have been able to insert a malicious style tag and malicious JavaScript code at the bottom of the page in two separate locations. With the help of some JavaScript code and JavaScript DOM objects and properties, the attacker has injected his obfuscated malicious code. This code is difficult to decode with the help of tools like Malzilla or online services like This blog will explain how to decode such malicious hidden Iframes by properly reading the code step by step. Let’s start by formatting the code.

    The above code contains one style sheet defined by “#c19”. After further inspection of the code, we determine that variable “WnmaQ” is defined with function “YYSXc()”. After that, there are 3 other variables defined, with 2 of them containing garbage or useless functions and then there is a call to the original function by accessing “Wnmaq.YYSXc()”. This means this code will call the function inside the first defined variable which is “Wnmaq”. Now let’s format that function and break the code into parts so that we can decode it step by step. Here is first part of the script,

    Looking at the code above, we can see there are some garbage or useless variables and functions are declared for no purpose, such as variable “l”, “v” and function “nB()”. There are many such garbage variables and functions declared throughout the script. They are never used for any significant purpose. So we will skip those dirty useless variables, functions. We will only concentrate on useful variables, code and functions used for decoding this malicious JavaScript. There is variable “g” declared with a “new Date()” function, which is in the form of an array. The first array element is a year and second is a month and so on. Then variable “o” is defined with a “g.getMonth()” function which means variable “o” will contain value “10” which is the second array element and called as month. Then variable “r” will contain the string “from10e”. The value 10 in this variable and is replaced by the “CharCod” string, so finally we have an interesting string in variable “r”, which is nothing but “fromCharCode”. Variable “i” is defined with object “document.styleSheets”, which will return list of style sheets. Let’s decode the second part of the main script,

    The above “for()” loop will actually extract the array data from the style tag defined earlier. I have put some comments inside the image to better explain the components of the code. Initially, variable “q” is matched with elements corresponding to the style sheet rule with the help of the “.selectorText” property. If the loop matches the string”#c19” of the style sheet, the code will continue. The next variable “w”, actually retrieves the array from the style sheet rule with the help of the property “.style.backgroundImage”. Now, we finally have useful variables. At this point, we should test to ensure everything seems reasonable. Let’s create a simple “test.html” file and add only important variables, style sheet tags and code inside the HTML file. We will test what the variable “w” will contain after above code with the help of “alert()” function. The sample HTML file is shown below:

    We have removed everything and added only those variables which we decoded earlier. We should get array values from style tag. Here is what the variable “w” will contain after running above file.

    So, the second part of the script just retrieved values from style tag. This shows our analysis is on the right track. We will keep this “test.html” file as it is and will add more interesting code after additional analysis. Let’s look into next part of the main script:

    The above code explains that variable “c” will contain string called “split” and variable “m” will contain array values separated by commas. The variable “k” will contain a value which will be the array length divided by 2. We will add all above 3 lines of code into our “test.html” file and will then alert the value of “k” for our purposes. The variable “k” will contain the value 90 if you run the modified “test.html” file. The above code also contains garbage code as mentioned earlier. Let’s decode the last part of the main script,

    The above code is the last part of the main malicious script. Here we will finish the decoding of the code and will come to determine the main malicious code behind this. As analyzed earlier, variable “k” will contain value 90 and this “for()” loop will run 90 times. The function “parseInt()” is used to obtain the exact integer. The variable “o” will contain the month of the date object, which is 10. The variable “r” contains the string “fromCharCode”, which we found earlier. So finally variable “j” will look like,

    j += String[“fromCharCode”][rZ];

    The loop will continue and variable “j” will be appended with characters retrieved from above expression. This is the main code behind the entire script. The last variable “kW” contains the JavaScript function “eval()” and then there is call to this function with parameter “j”. This tells us that the malicious content will evaluate the code inside the variable “j”. Let’s add this “for()” loop inside our earlier “test.html” file and we will alert the value of “j” to find out the hidden code. This is what our final “test.html code will look like:

    We have only added useful variables, loops and JavaScript code in the above file. We have removed useless variables and functions from the main script. Now here is what you see when you run the above file:

    The malicious Iframe pointing to malicious domain is finally revealed. The attacker has created the malicious JavaScript code with the help of a style tag to generate a malicious Iframe. This process can be difficult to analyze and tools or services may fail due to the complex nature of the code and various tricks used by attacker. However, if you have a little patience and good eyes, it is very easy to decode such malicious JavaScript code by understanding the flow of the code. That’s it for now.

    Happy Decoding


    Thursday, February 10, 2011

    Browser plugins and security considerations

    Firefox is an ideal browser platform for creating add-ons. Firefox plugins have access to the entire browser, without any restriction. This allowed me to release two plugins to improve the security of Firefox users (Search Engine Security, and BlackSheep), and a third one is in the works, but the power of Firefox plugins can also be used with malicious intent.

    Full access to the browser and the computer

    Firefox plugins have access to the entire browser, including HTTPS content and also to the operating system. This means that any add-on can:
    • see login/password credentials in clear text, even over HTTPS connections
    • send back the credentials to any website
    • modify the web pages seen by the user (often done by Adware)
    • add/delete/modify files on the computer (even outside of the Firefox directory)
    • run executables, either embedded in the plugin or downloaded at any point
    The ability to see content in clear that is sent over HTTPS is unique to browser plugins.

    There is no concept of permissions or sandboxing for Firefox plugins. Once a user installs a plugin, it has full access to the computer. This is why Firefox imposes a 3-second warning message before you install a plugin. You'd better be sure you trust it fully!

    Are you really sure you want to install this add-on?

    Firefox plugins have been created to steal credentials or insert advertising in web pages.

    No permissions checks or sandboxing

    Google Chrome, on the other hand, requires every plugin to stipulate which domain can be accessed. They are shown to the users before the plugin is installed. It also has more limited capacities, like the inability to listen to all HTTP connections, which ultimately makes Chrome plugins safer, but less versatile.

    Firefox has no restrictions at all on what the a plugin can do, or access. Some versions of Windows or various security tools will ask permission from the user if a plugin access files outside of the Firefox folder, or tries to run an executables. However, this was not the case on my Windows 7 Home version.

    The only security measure implemented in Firefox is to forbid the installation of plugins from websites other than the official Mozilla site, by default. Users must first allow a domain to install plugins from, then click on "Install" after a 3-second wait period.

    Plugin installation is blocked by default

    Official Mozilla add-ons review cycle

    All add-ons submitted to the official Mozilla Add-Ons site go through a manual source code review. This process attempts to ensure that the plugins are not malicious. Each update of the plugin also goes through a manual review. The down side is that it takes days, or weeks, for every little change to be approved.This is why I prefer to release plugins on our website first and wait until the add-on is stable to submit it to the Mozilla site.

    Manual code reviews of Search Engine Security
    The only way to be reasonably sure that a plugin is safe is to download it through the official website. There used to be a loop hole, though - add-ons used to be allowed to be listed on the site, but hosted somewhere else. In that case, the official reviewers could not guarantee that code downloaded by the users was the same as what they approved. This option is not available anymore. All add-ons and updates have to be hosted by Mozilla and be listed on their site - that is why BlackSheep is lot listed anymore.

    Silent plugin installation

    Whenever you install a new plugin, it takes effect only after you restart Firefox. Firefox also display a box showing which plugins were newly installed.  However, there are ways to install a plugin silently.

    An attacker could trick users into downloading a program that would do a silent installation of a malicious plugin in order to get full access to the user surfing data, including login and password information sent over encrypted channels.

    New add-on

    All the add-ons are stored under the Firefox profile, a known location, within their own sub-folder. A new folder can be created and filled with a malicious plugin. Firefox keeps information about the existing add-ons in three files: extensions.rdf, extensions.ini and extensions.cache. If any of these file are deleted, Firefox re-builds them automatically at the next start up, without informing the users.

    After adding the malicious plugin to the Firefox profile, the three files should deleted. This will not prevent the current Firefox session from running or impact existing plugins. When Firefox is restarted, these files are re-generated, and the new plugin is added to the list without any notification to the user.

    Add-on overwrite

    Each plugin includes the file install.rdf, which contains metada data about the plugin: name, version, home page URL, etc. The parameter updateURL tells Firefox which URL to use to check for new updates. Malware can simply add or modify the updateURL value for existing add-ons, then remove extensions.rdf. The new updateURL can be used to force the update of a plugin with a version that contains the old add-on plus malicious code.

    With this technique, the malicious installation is completely invisible.

    The Firefox plugin framework is very powerful. There are not adequate protections put in place to ensure the integrity of plugins after they are installed. I hope some future version of Firefox will put additional protections in place to avoid tampering of installed plugins.

    -- Julien

    Monday, February 7, 2011

    Facebook and the HTTPS/Security Paradox

    Last month, Michael published his 2011 security predictions. His second prediction in his list of 10 discussed SSL Only Sites:
    In 2011, expect a handful of major vendors to finally tackle this challenge head on and deploy SSL only websites.
    Facebook recently announced on their blog that users will have the ability to have all of their transactions encrypted via HTTPS. This is a step in the right direction for protecting your account and your privacy - particularly when using public wifi. I have already blogged about session-id stealing from HTTP transactions (sidejacking), which was further publicized with the release of FireSheep and BlackSheep. Unfortunately, on Facebook, usage of HTTPS is not enabled by default - users still have to enable this setting within their Account Settings page.

    There have been a number of security concerns and issues with Facebook- for example,
    • Koobface / malicious "videos" advertised and spread

    • Rogue Facebook Applications - here is a recent rogue "photo" app that I saw with relatively poor A/V detection (11/43):

    The bad guys are abusing popular web sites/services that users trust. As these sites move to SSL-only versions, while private information may be better protected, any embedded malicious content will be encrypted and potentially invisible from your enterprise's IDS/IPS. This is the security paradox that I speak of: moving to HTTPS for all transactions protects against sidejacking and protects user's privacy, but this also prevents inspection of network transactions for malicious content ... this is potentially a very scary "blindspot" within enterprise environments. This type of "blindspot" exists in other services as well, e.g., Gmail.

    However, all is not lost- there are several available security avenues for security-conscience organizations that allow Facebook within their environment:
    • Host-based protections:
      • Facebook security apps
      • Client anti-virus
      • Browser plug-ins
    • SSL-inspection engines:
      • SSL-proxy with content inspection (appliance or SaaS-based)
    The difficulties with host-based protections include manageability and information feedback (logs). SSL-inspection engines on the other hand, can be easier to manage and provide centralized, aggregated logs (this is particularly true of the SaaS-based models). SSL-inspection does however require the ability to temporarily break "end-to-end" encryption which necessitates trusting the proxy and web server certificate validation process. This often causes confusion for management when making the decision on whether to inspect SSL transactions on the network or not.

    SSL-inspection engines work by establishing an SSL encrypted session between the web client and proxy, which separately creates a second SSL session between the proxy and the web server. The proxy makes the actual requests to the web server, handles/inspects the received content, and forwards it to the client. In this model the client must trust the certificates from the proxy, and it is important for the proxy to handle certificate verification of the web server.

    Zscaler provides SSL-inspection as part of its solution.

    Our customers also have the ability to set policy to block transactions to all/or certain social networking sites. Currently, about 16.26% of our customers had transactions that were blocked due to a social networking policy rule.

    As Facebook and other popular web services move to SSL-only, enterprises will have a dilemma: (1) accept the risks and rely on host-based protections alone for this content, (2) incorporate SSL-inspection technologies, or (3) incorporate policy enforcement for the sites in question.

    Thursday, February 3, 2011

    Unchecked redirection + URL shortener = Spam

    Recently, I found several legitimate sites, with bad coding practices,  used to redirect users to spam sites with the help of URL shorteners. Here is how the scam works:
    • The legitimate sites have a warning page for all links to external sites (i.e.
    • The warning page can be used to redirect users to any domain, including spam sites and malicious pages (i.e.
    •  Spammers use a URL shortener like to hide the long URL (i.e. redirects to which redirects users to
    Most URL shorteners do some checks on the final URLs to prevent spammers from using their service. By using a legitimate intermediate site, the attackers prevent URL shortening services from checking the true final destination and therefore prevent blacklisting or blocking of the shortened link.

    One example of such redirection pages is Change to any URL. I've seen this page used to redirect to the rogue pharmacy

    The redirection is not done by the standard Meta refresh tag (meta http-equiv="refresh" content="6;url="), but by custom JavaScript. Even if the URL shortener was looking at the HTML content to figure out the final destination, it would very likely not haven seen the redirection to an external domain.


    In addition to being used by spammers, includes a crosss-site scripting vulnerability: the link can be used to execute any JavaScript. The screen shot below was taken for the URL;

    Cross-Site scripting on

    Unchecked redirections is yet another security flaw that developers need to keep in mind when developing a website. Having a website widely used for spam will likely get it blacklisted by Google Browsing and other security and spam blacklists, preventing users to access any page on the website unless they dare ignore the scary warning message from their browser.

    -- Julien

    Wednesday, February 2, 2011

    Egyptian revolution ... back online

    In the days during the Egyptian Internet outage, a number of Egyptian's circumvented the outage through a variety of methods (reference). Speak2tweet is one example of a work-around in which Egyptians could phone in their tweets using the SayNow service. This service grew enormously in popularity in both posters and readers/listeners- we saw roughly a 362% increase in traffic to SayNow yesterday.

    Earlier this morning, Egyptian ISPs restored their Internet routes (reference). I wanted to publish a short post verifying that we are seeing a return of Egyptian client and server web transactions. Currently, we're seeing about 80% of the Egyptian client transactions to Aljazeera and much of the remaining transactions are to Facebook, Google, and MSN. The Egyptian web server activity has returned to what we had seen prior to the outage. We will continue to monitor and report anything that is interesting or unusual within Egyptian client or server web transactions.