Protect your self against Facebook spam: Zscaler Tool for "LikeJacking" Protection

Facebook widgets, including the "Like" buttons, are often used to spread spam and propagate scams. Typically, the scammer creates a page with a fake video player. Users are tricked into clicking on Facebook Like buttons hidden behind a fake Play button. This is called Likejacking, and it's a specific form of clickjacking. I have posted a Youtube video showing in June that explains how these Facebook widgets are disguised.

I previously posted a bookmarket - a piece of JavaScript that can be executed on any page to display hidden Facebook widgets on the page. I wanted to go a step further and offer good protection against Likejacking, or any type of clickjacking with Facebook widgets (Facebook comments, Facebook login, etc.).

You can install the free Zscaler Likejacking Prevention tool for Firefox, Google Chrome and Safari. The extension offer 2 primary features:

• Information about the page: does it contain Facebook widgets? Are these widgets hidden?
• Protection against hidden widgets: the application requires explicit confirmation from the user when clicking on a Facebook widgets on a suspicious page

Page information

On Firefox and Chrome, an icon is displayed in the URL bar when a page contains at least one Facebook widget. If the page is suspicious, meaning hidden widgets were detected, the icon has a red background. You can use http://www.zscaler.com/research/plugins/likejacking/example.htm as an example of a suspicious page.

Suspicious page found in Firefox

If the page is safe, meaning the widgets are not hidden, the icon background is green. This allows users to have a quick understanding of the safety of the page.

Safe page found in Chrome

Safari has the same functionality, but uses a toolbar instead of an icon.

Suspicious page found in Safari

You can obtain more information on the page -- either by clicking on the icon, or "More options" in Safari -- including:

• how many widgets were found on the page
• whether the page is suspicious or not
• what protection was applied on the Facebook widgets

Information, and actions, for a page with Facebook widgets (Chrome)

The popup (Chrome), or toolbar (Safari and Firefox) also let users take some action on the page: they can whitelist the current domain (see more below), manage their preferences, or display the hidden Facebook widgets on the page.

You can also report back to Zscaler, any page that was classified improperly by clicking on "Report an error". This will open a new tab in your browser and  send you to a form on the zscaler.com website. We will use this information to improve the add-on.

Display hidden widgets

As you can see in the Youtube video, it is possible to expose the hidden widgets. The extension can modify the source of the page (opacity, height, weight, z-index, overflow, etc.). You can try this feature on http://www.zscaler.com/research/plugins/likejacking/example.htm.

Hidden Like buttons exposed in Firefox

Explicit confirmation

You can choose your level of protection in the preferences:

• Delete all Facebook widgets - Choose this option if you never use "Like" buttons on external sites. You can always whitelist a domain to keep the widgets on a particular site.
• Always ask for explicit confirmation - A popup will warn you that you clicked on an element that is trying to post to your public profile. You can decide to stop the action, or to let the page post to your profile. This is a good option if your rarely click on "Like" buttons.
• Ask for explicit confirmation only on suspicious pages with hidden widgets - This is a good balance between security and productivity. It is the recommended setting.

Explicit confirmation in Safari

You can also whitelist domains so that no protections are applied on a given site. The popup, or toolbar, can show you what action was taken on a page -- for example confirm, remove, or ignore (no protection applied).

Extension preferences in Chrome

Some notes

The extension does not affect the ability to use the main Facebook site; it protects users only on other sites that use widgets from Facebook.

Some Facebook widgets are hidden by design. This is normal, and the the extension will not list them as suspicious and will not apply any protection on those.

I will post another blog on the process of creating the plugin for different browsers to explain the challenges I faced on each platform.

-- Julien

Deep Javascript obfuscation can make exploits easier to detect

UPDATE: AVG displayed false alerts about the obfuscated Javascript codes samples displayed in the post. These samples are all harmless. I have replaced these codes samples with screenshots.


Minification, packing, obfuscation

Javascript code is usually pre-processed before it is served to users in order to make it smaller, resulting in a faster page load times, or to obfuscate it.

function add(one, two) {
    return one + two;
}

An example of original source code

Minifier

The most common form of pre-processing involves minification. The source code is stripped of white space, comments, etc., in order to make it more compact. Some minifiers can also rename internal variables to make them shorter. The minified Javascript is less readable for humans, but not to automation tools or security scanners. It is a common practice to serve minified Javascript either inline, as part of an HTML page, or in external sites, to reduce the loading time of pages. Google, Amazon, and most major websites use this technique.

function add(a,b){return a+b}

Example of minified Javascript

Packer

Then webmasters try to go further and additionally reduce code size by leveraging packers, such as using a base64 encoding. The source code is endoded in the new base, and decoded through Javascript in the browser. This results in a smaller code (if the original code is not too short) that is harder for humans to interpret and often harder for security tools to inspect.

Packed Javascript is not widely used because the smaller file size is balanced by a longer execution time in the browser to decode the Javascript.

Example of packed Javascript (line break inserted for readability)

Obfuscator

Obfuscation is done for the sole purpose of "hiding" the original code. Obfuscated code often results in a larger code size than that of unprocessed Javascript. The resulting code is unreadable by humans, and once again, complicates parsing for security scanners. A slight code change in the original code can also create a completely different set of obfuscated Javascript. That means an attacker can create many versions of the same original code and each will look very different from the others.

Example of lightly obfuscated Javascript

Obfuscated exploits

There are legitimate uses of obfuscated Javascript. For example, obfuscation can be used to hide e-mail addresses from web crawlers. Obfuscation is also commonly used by many advertising networks.

But Javascript obfuscation is widely used for malicious purposes. Attackers obfuscate their exploits to bypass security tools. They can also easily change the code on each site they infect, so that one detected malicious page does not result in all other exploited pages being detected.

Sometimes however, extreme obfuscation can make it easier to detect malicious code. When Javascript looks very different from minified, packed or even common obfuscation code patterns, they really stand out. It is sometimes easier to detect the obfuscation itself rather than the underlying exploit.

Metasploit is a popular and powerful exploitation framework, which includes a number of browser exploits. It goes to great lengths to obfuscate the exploits: most variables are generated randomly for each run and the Javascript code is heavily obfuscated overall. As a result, Metasploit generated HTML code can really stand out:

• the code density is unusual: they have very long variable names, spaces at the beginning of lines, several line breaks in a row, etc.
• repeatable patterns
• most ActiveX objects are called with new ActiveXObject(String.fromCharCode(
• reassignment of the unescape Javascript function to a variable: <...> = unescape;
• the decoding loop uses some unusual pieces of code: .toString(16); unescape(unescape(, etc.

as a result, it can actually become easier to detect the exploits coming from Metasploit. We've seen other examples where the attacker goes a little too far to obfuscate his code, and actually make it easier to recognize.

Obfuscation done right can make it harder to detect and understand exploits. Crazy obfuscation does the opposite.

-- Julien

Inline Detection of Evil JavaScript

Exploit kits are a much more common threat on the web than they used to be. In order to evade detection, the kits frequently contain logic to obfuscate, or hide, the meaning behind the content that they serve to the victim. Additionally, with each visit to the exploit page, the obfuscation techniques will differ slightly so that static, content signatures will be unable to detect the threat. Other threats contain obfuscated JavaScript (JS) which sets up the page to exploit a vulnerability and launch a payload (for example, "spraying" the heap with shellcode). Still other threats inject obfuscated JS into legitimate sites, which after decoding embeds a hidden (0-pixel) IFrame to malicious content. As we have seen in the past, the JS encodings vary greatly with each incident, and many instances are encoded multiple times and may contain non-standard JS (reference past blog posts, such as "More and more obfuscation being used in the malicious scripts"). While some signatures have been written for things like generic heap spraying and other maliciousness within obfuscated JS, the bad guys are constantly updating their tactics to evade detection. Anyway, the point that I'm getting at is that scalable (think ISP), inline deobfuscation of JS is something that is *very* difficult to implement.

One way of coping with this problem is to implement a number of efficient checks to analyze and score the JS inline for likelihood of maliciousness (JS heuristic). Pages that meet a certain score threshold may have additional inspections done or the page may be blocked outright. After doing some research and testing against some malicious and benign sites, I came up with a small number of checks that can be implemented inline and also produced some compelling results. While I won't divulge all of the "secret sauce", I wanted to share two pretty interesting checks that I'm doing against JS.

Fun with N-gram Analysis

A former colleague and I had discussed character based analysis of domains to provide indications of suspicious / malicious usage. For example, the Avalanche botnet has a domain registration and fast-flux infrastructure that is frequently used for hosting Zeus, phishing, and money-mule recruitment sites. Typically, Avalanche bulk registers domains that often do not have any correlation to any particular word or alias, for example:

erasv
jjkk
yuuikom
yy1azsva
zah7kio
zyuojli
...