Aurora exploit still floating ...

It's been around two years since Microsoft released a patch for the IE 0day famously known as the Aurora exploit (CVE-2010-0249). We had blogged about this in the past when it was first seen in the wild on the 'GOV.CN' domain. This vulnerability targets IE version 6. Despite the passage of time, we continue to find live exploits for this vulnerability. Recently, we found a new URL which is serving the Aurora exploit code.

Exploit URL: hxxp://www.artbridal.com/bizcodi/gm/news.html

Let's take a look at the exploit code being delivered.

 

The exploit is delivered via obfuscated JavaScript code, although the level of obfuscation is not very high. Some of the strings and JavaScript function names are been obfuscated. The following is a snapshot of the de-obfuscated code.

If you observe the first image, the SPAN tag holds an IMG tag on which the 'onload' event calls an event handler  function 'eve'. This in turn creates an event object called 'e1', using the 'document.createEventObject' method. Then, by using an '.innerHTML' property, it assigns a null string to SPAN object 'sp1', but instead, the 'sp1' object is removed. In the function 'eve', the freed object is referenced, causing memory corruption in the form of an access violation in IE. To exploit this condition, the exploit code uses a typical heap spray technique to load the shellcode into memory for the execution. When the shellcode is executed, it tries to download a malicious file from the URL 'hxxp://fly-tld.ru/w.php?f=47&e=3'.  For a more detailed analysis, you can refer to this blog.

To obtain the aforementioned URL, the PE executable file was formed and extracted from the shell code in the exploit. The EXE was then examined using a debugger to extract the URL as can be seen below.

This URL is down at the moment, so further post exploitation analysis was not possible.

Reports:

VT URL Scan on found URL : 4/51 detections.

VT File Scan on EXE formed from Shellcode: 27/41 detections.

Various other URLs that have been seen in the past with similar patterns - '/w.php?f=(\d){2}&e=(\d){1,2}' include:

hxxp://synergyledlighting.net/w.php?f=56&e=4
hxxp://nicesextubes.co/w.php?f=18&e=6 
hxxp://iplaecrcocee.com/w.php?f=26&e=2
hxxp://iplaecrcocee.com/w.php?f=26&e=2
hxxp://examine.arsb.co.uk/w.php?f=20&e=2
hxxp://exciting.simssocialcheat.com/w.php?f=22&e=2
hxxp://oyacromifh.com/w.php?f=26&e=2
hxxp://eteaescopr.com/w.php?f=26&e=2

The obvious reason behind attacking old CVE's is the belief of attackers, that there are still un-patched and outdated browser's out there on end user machines. Sadly, they're correct. To avoid such attacks we suggest updating browsers with latest patches and migrating to the most recent version of the browser. 

Stay updated, Stay Safe!

Pradeep

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.

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.

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

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.

Download HTTPS Everywhere for Internet Explorer

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).

Download HTTPS Everywhere for Internet Explorer

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.

Internet Explorer Protected Mode in Windows 8

Microsoft Introduced Protected Mode in Internet Explorer with Windows Vista in 2006. With Windows 8, Microsoft added Enhanced Protected Mode. Protected Mode aims to keep users safe by restricting what BHOs (Browser Helper Objects, aka browser extensions) and plugins can do inside Internet Explorer.

Protected Mode enabled by default in IE 9

Protected Mode

Before I talk to the changes made in Windows 8, let me explain what Protected Mode does in Internet Explorer versions 7 through 9, especially when it comes to browser extensions. Internet Explorer, along with any extensions and plugins, run with a low integrity. This means that they have limited access to the system: read/write access to the file system, the registry and limited ability to run executables.

Limitations

Internet Explorer extensions have write access to /AppData/LocalLow and a few folders useed by Internet Explorer to store cookies and favorites. Any untrusted application can write to LocalLow without triggering any User Account Control (UAC) violations, including applications deployed with ClickOnce. Zscaler Safe Shopping for Internet Explorer for example, creates a sub-directory in LocalLow to store the list of fake stores.

Extensions can run executables that have a low integrity only. Windows applications have a medium integrity, which means that Internet Explorer cannot run any application without an explicit permission from the user (UAC popup). An extension can therefore only launch an application with a low integrity, which means that it will have limited system access.

Write  access to the registry is also limited. An extension can write to the registry only under HKEY_CURRENT_USER\Software\AppDataLow\Software.

Read access

Protected mode does however give read access to the entire file system. A malicious extension could therefore upload all your important files under My Documents to a malicious server, for example.

Integrity elevation

It is possible to run an executable of a higher integrity by setting up an Integrity Elevation Policy. Basically, an entry is added to the registry to specify which executable should be run by a low integrity process at a higher integrity, without raising a UAC popup. This entry has to be added as an Administrator. It cannot be added from within Internet Explorer.

Windows 8

Windows 8 introduces Enhanced Protected Mode to fill some of the security gaps of the current Protected Mode. The most important change is a limit on read access. Read access to the file system and Registry are more restricted. Unfortunately, this new Protected Mode breaks many existing plugins. Microsoft has therefore decided to turn off Enhanced Protected Mode for Internet Explorer by default. So, by default, Windows 8 and Internet Explorer 10 do not offer any additional protection against data leakage by malicious browser extensions.

The most important take away from this is that Protected Mode still lets lets all extensions read the entire file system and arbitrary applications can be launched silently.

Abusing ClickOnce

Many web-based attacks try to fool the users into installing a malicious executable by faking a native application: fake AV, fake Flash updates, etc. These pages are well designed, but you can always tell it is not a native application running.

In a previous post, I described the ClickOnce deployment for Internet Explorer. ClickOnce is a a way to easily deploy applications on Windows computers. When a user clicks on a link that points to a ClikckOnce deployment, a new popup is opened. This popup is very different from any popup or window opened by Internet Explorer. If the user clicks on Install, the executable is downloaded and executed in a single step, without a way to cancel the installation at any point.

If the user minimizes the browser, the popup remains visible on the screen. The ClickOnce popup is a native application and it is therefore independent from the browser.

ClickOnce popup

ClickOnce would provide a great opportunity to trick Internet Explorer users into installing software. There are three fields displayed in the popup and they can all be abused to look like the user is going to install legitimate software from a legitimate vendor:

• Name: Supposed to be the name of the software being installed. In my example, I set it to 'Windows Update'.
• From: Domain where the software will be downloaded from. The space is limited. Although the most important part of a domain is on the right side (TLD and top-domain), the right side is actually truncated. Use a very long domain, as I did in the example shown and it looks like the  software is hosted on a sub-domain of microsoft.com (click on the image above to get a bigger version, and check the From domain).
• Publisher: Who created the software. The Publisher is taken from the code signing certificate that was used to sign the ClickOnce deployment. An attacker can use a legitimate certificate with a name that sounds legitimate, or use a stolen code signing certificate (like Flamer). A self-signed certificate can be used to get the Publisher name as Microsoft, for example, but a red warning would be shown on the popup. Unfortunately, the red shield warning may not adequately scare users away...

It is pretty easy to create a ClickOnce deployment for any executable. The web server simply needs to send a specific MIME type, which is also easy to configure. I have not seen any broad attacks using this method. It is however something to keep an eye on as it would be a rather effective tool for social engineering attacks against end users.

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!

Stolen code signing certificates are your worst nightmare

Flamer used spoofed code signing certificates from Microsoft. This was done to make it appear that the malicious content was actually software delivered by Microsoft.

You have likely seen the use of code signing certificates when Windows pops up a User Account Control (UAC) warning to ask for your permission to make a change to your system. If the executable is signed by a Trusted code signing certificate, the UAC will display a "Trusted Publisher" notice, otherwise it will display an "Unknown Publisher" notice.

Trusted executable

Executable not signed

However, you can actually do much more with a stolen code signing certificate. Using the Microsoft ClickOnce technology, it is possible to download, run and install any executable on the user's desktop just with one click on a regular HTML link. Users do not have a way to stop the executable from being downloaded and installed once the link has been clicked.

If you use a valid code signing certificate to sign a ClickOnce deployment file and the certificate is not part of the user's list of Trusted Publishers, you will receive the following popup:

ClickOnce abused. You can choose between Install and Run.

You may have noticed several elements that make this popup look more reassuring to a user than the usual download/run popup from Internet Explorer:

1. The popup is not actually part of the browser, it is actually a separate application.
2. It claims to be a Windows Update. If the user clicks on the link, they will be sent to http://support.microsoft.com/.
3. The software seems to be hosted on a sub-domain of microsoft.com.
4. The publisher (myself), is trusted.

This looks like the real deal - Microsoft is asking me to run a Windows update, but it is actually a program I wrote myself! The "Name" attribute is arbitrary, it can be set to anything that looks official by the author. Also, the link, which I chose to have point to http://support.microsoft.com/, is not related to where the software is installed from.

If you host the application on a sub-domain that is very long, the popup will truncate it, making it look like a sub-domain of microsoft.com if you carefully craft the URL. Since the popup width is the same on all Windows versions, regardless of the user screen resolution, such a misleading URL is easy to craft.

The valid code signing certificate cost me $59, but you can get one for free. With a "stolen" certificate from Microsoft, the UAC would show Publisher: Microsoft.

Trusted Publisher

You can bypass the UAC warning completely if the application is signed with a code signing certificate that is part of the "Trusted Publishers" list on the user's computer. In that case, there is no warning and no cancel button - the application is downloaded and run automatically. Pretty scary!

The good news - the "Trusted Publishers" list is empty by default on Windows. The bad news - some software vendors install their own certificates along side a separate software installation. Your administrator may also push your company's certificate to the list in order to deploy software automatically. If one of these certificates is stolen, or if the attacker can fool users into installing a certificate of his choosing (especially if it is signed by Microsoft...), then any application can be installed on your computer without your knowledge.

To verify if you have any certificates installed in your Trusted Publisher list, run "certmgr". In the right pane, click on "Trusted Publishers". if there are certificates, click on "Certificates" to see the list. To be safe, you should remove any that you don't explicitly recognize as needing to be there.

My Trusted Publishers certificates

There is no need to find vulnerabilities to install software silently on computers when ClickOnce lets you do so legitimately.

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:

• StackOverflow: the BHO tag has only 249 questions, but still a good source of information
• The Code Project has several tutorials and code samples
• vcsjones with 5 blog posts about managed BHO
• Free VPC images to test your add-on different versions of Windows and Internet Explorer
• MSDN documentation of the WebBrowser class

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.

Why the web has not switched to SSL-only yet?

With the session-sidejacking issue highlighted once more by Firesheep, a many people have asked me why more websites, or at least the major players (Google, Facebook, Amazon, etc.) have not enabled SSL by default for all communication. Indeed, encryption is the only way to ensure that user sessions cannot be easily sniffed on a open wireless network.

This sounds easy - just add an s after http in the URL! It's not actually that easy. Here are some of the challenges.

Server overhead

The obvious issue is that encrypting all HTTP sessions requires additional resources on the sever-side. I've seen numbers showing 10% to 20% CPU overhead for SSL. Having to add 10% more servers is a big deal when you're dealing with thousands of them like Facebook and Google. However, the overhead can actually be much higher on specialized severs, which efficiently serve static content (such as images) directly from memory (think memcached). In this case, the processing power required is easily multiplied by a factor of 10. Of course the SSL encryption can be offloaded to a proxy or other external hardware, but you have to add the cost of managing a more complex topology as well as buying the new hardware.

Increased latency

SSL also has a perceived performance issue for the client (i.e. the browser). For  each new session,  SSL encryption must be set up between the client and server. This means a few more packets must be sent back and force before the actual HTTP data is received. This happens for each page load, and also for each domain.

1 HTTPS transaction: 4 SSL handshake packets, 6 data apckets

A typical  Facebook page (like the News Feed) contains HTML elements (images, CSS, JavaScript) from more than 10 domains.  This means the full SSL handshake is done over 10 times on each page. This in turn makes pages load more slowly. The problem is amplified if the user's connection has high latency, as it would on a cell phone.

4 of the 10+ domains used on a Facebook page

Challenge for CDNs

All the major websites use a Content Delivery Network (CDN) to deliver static content quickly to their users. Some have their own (Facebook, Google), but others use third parties such as Akamai.

The same website can be served from hundreds of CDN servers based on their geographical location, and each CDN server can handle several hundred websites. Most website owners don't want users to see content being downloaded from akamai.com, so they use an alias. For example, static.amd.com could point to a248.e.akamai.net.

Each CDN therefore serves different content based on the Host header received (static.amd.com for example). This creates a problem. The SSL handshake is done first,  then the HTTP data is sent. That means the SSL server must send an SSL certificate to each client without first seeing the host. In brief, the SSL server sends a certificate based on the destination IP address, not based on the HTTP hostname.

The second fact to keep in mind is that an SSL certificate is valid for one domain only.  If a user goes to www.example.com, the certificate has to be signed for www.example.com, not example.com or example.net.

SSL certificate for www.facebook.com

For example, http://www.amd.com/ is served entirely through Akamai. So what happens when you use https://www.amd.com/ ? You get a warning, because the Akamai CDN server sends a certificate valid for itself (a248.e.akamai.net), not for www.amd.com.

Wrong SSL certificate issued for akamai.net instead of amd.com

Wildcard certificates are not enough 

You don't need to use a CDN to have troubles serving the right certificate for a given hostname. Most sites can be reached with and without www: http://amazon.com/ and http://www.amazon.com/ brings you to the same site. When a site wants to handle several sub-domains (www.site.com, mail.site.com, static.site.com, etc.) easily, it can buy a wildcard certificate. This certificate is valid not just for one domain, but for all sub-domains: *.site.com. Unfortunately, this wildcard certificate is not valid for site.com (no sub-domain). For that, a separate certificate is required. This is again a challenge if the same IP address servers both site.com and www.site.com.

Dropbox has this exact issue. Access to https://dropbox.com/ delivers a warning to he user:

Dropbox's wildcard SSL certificate is not valid for dropbox.com

Mixed HTTP/HTTPS: the chicken & the egg problem

Yet another issue - HTTPS pages must contain external object from HTTPS URLs only. You cannot match HTTP and HTTPS on a secure page, otherwise users receive a warning message. Websites however rely on a significant amount of content from external sites: Googole/Comscore Analytics, Google/Twitter/Facebook connect, ads, etc.

Google Adsense, for example, cannot be used on a secure site. All sites which rely on this advertising network to make some money need to forget about HTTPS and about protecting their users!

Each website needs to make sure that all their partners, sometimes much bigger than they are, fully support HTTPS before they switch to it.

Warning about external HTTP objects on a secure page

Warning are scary!

It is not easy for a site to switch to SSL for all content. One mistake, and users will receive a warning. And they're scary! Internet Explorer 8 explicitly suggests that the user not to enter a site with an SSL certificate error.

Scary warning on Internet Explorer

Websites really don't want to scare away potential visitors!

But it is possible

Moving from HTTP to HTTPS is easier said than done. This must be carefully planned. All cases have to be thought through to avoid warning messages. Despite that fact, all of the challenges discussed in this post do have technical sotuions.

This can be done. Google has already moved Gmail to HTTPS by default, but they have not done the same for their other services...

-- Julien

Analysis of multiple exploits

The most common type of malware seen in Blackhat spam SEO is the fake antivirus. But I also see other types of exploits from time to time. This week, the same malicious page came up on different domains: 4rukel.cz.cc, 4lofs.tk, 1polidsf.co.cc, 1barede.co.cc, 3timesto.tk, 4greaix.cz.cc, 4krudi.cz.cc, etc.

This page is interesting because it uses exploits rather than social engineering to install the malicious code. Below are the details of the exploits / malicious code.


Heavy obfuscation

The JavaScript code is heavily obfuscated. It cannot be de-obfuscated by a simple copy-paste of the code into Malzilla, some of the decoding has to be done by hand.

Original malicious code

One common technique, used in this page, to break the JavaScript de-obfuscation tool is to make references to the DOM. On this page, part of the JavaScript code is included in a textarea HTML tag. It is retrieved and executed later with code like this:

eval(document.getElementByTagName('textarea')[0].value);

While executing the obfuscated JavaScript code, new HTML elements are added to the page, and used to store values or JavaScript code retrieved again later in the JavaScript code.

First de-obfuscation pass generated new obfuscated JavaScript code!

Fortunately, all the JavaScript code is inline. There is no external file, which always make the de-obfuscation harder.


Multiple exploits

Like many malicious pages, several exploits are included on this page:

1. 2 malicious Java applets, using different techniques for Internet Explorer and Firefox
2. PDF exploit
3. Quicktime '_Marshaled_pUnk' Remote Code Execution Vulnerability
4. Heap spray attack
5. Internet Explorer MDAC exploit
6. Internet Explorer "iepeers.dll" exploit
7. 3 Flash exploits

Part of the code for the Java exploit

I believe these exploits come from different sources because the coding style of the various functions varies greatly.


This malicious page tries the different exploits until one is successful. Users need to make sure they keep both their browser and their plugins up to date.

-- Julien

Comparison of Malware protections: Google Safe Browsing, Microsoft SmartScreen, etc.

All modern web browsers now include protections for malware. They include a list of known malicious URLs, and compare each address visited by the user against this list. If the URL is recognized as malicious, a warning message is displayed in place of the HTML page. They also protect against Phishing sites, but I won't dive into this feature during this post.

SmartScreen Filter warning in Internet Explorer

Chrome, Safari and Firefox 3.x use Google SafeBrowsing, while Internet Explorer 8 has SmartScreen Filters and Opera includes lists from Netcraft and TRUSTe. Note that it took Safari more than 20 minutes for SafeBrowsing to start working after I upgraded from Safari 4. It did not show any warning, informing that malware protection was disabled while it was retrieving the database.

Safari waning message

I was wondering how well these protections work against current threats. Since antivirus doesn't perform well against viruses spread through fake AV pages, fake videos, or against malicious jar files, I wondered if these browser block lists would keep users safe against current spam SEO attacks.

I've tried a few domains for each type of attack, using each browser. All the malicious domains were directly identified from within Google search results, using popular search terms.

Protection against fake AV pages

I first tried various new fake AV domains as well as subdomains for xorg.pl (hostguard-31p.xorg.pl, hostguard-47p.xorg.pl, ubersaving26.xorg.pl, etc.), a domain that has hosted fake AV pages for months.

Browser	New domains blocked	Xorg.pl subdomains blocked
Firefox 3.6	7/7	5/5
Internet Explorer 8	2/7	0/5
Opera 10.5	0/7	0/5

Google Safe Browsing is very good at blocking fake AV pages. We report to Google on fake AV domains we identify, which they don't block, but we're noticing that there are fewer and fewer which they don't already block.

Protection against fake video codecs

This type of malicious pages seem to have staged a come back and we're seeing them more and more frequently since last week-end. In this scenario, the user is tricked into downloading an executable disguised as a video codec or new flash version.

Browser	Urls blocked
Firefox 3.6	2/6
Internet Explorer 8	5/6
Opera 10.5	0/6

Internet Explorer did a great job at flagging the fake video sites. Google Safe browsing, surprisingly had a very low rate of success.

Protection against Java/PDF/Flash exploits

The number of Java exploits has also increased dramatically over the past few weeks.

Browser	Urls blocked
Firefox 3.6	2/4
Internet Explorer 8	1/4
Opera 10.5	0/4

Opera did not flag any of the malicious sites. Their security blacklists may be targeting phishing only. To make sure the security notification worked, I attempted to visit a phishing site and Opera did warn me.

Opera phishing warning

-- Julien

fake Antivirus: your blacklist and antivirus do not protect you

We have spent a fair bit of time discussing fake AV pages as they represent approximately 60% of the malicious content associated with Search Engine Optimization (SEO) attacks, according to Google. As shown in past Zscaler blog posts, it is not uncommon for Google to include malicious links in the first 10 pages of search results.

Users can do very little to spot these malicious links. Google shows a warning for only a small percentage of overall results, even days after malicious links first emerge, and antivirus browser plugins such as AVG tend to show such links as safe.

AVG plugin shows this link as safe. It is actually a redirection to a fake AV page

Browsers include blacklists of phishing and malicious sites. Firefox and Chrome use Google SafeBrowsing, while Internet Explorer uses SmartScreen Filter. Everytime the browser loads a URL, the web address is checked against a list of known bad sites to stop the user from going to a malicious destination.

Google SafeBrowsing has a pretty good history of blacklisting fake AV domains. We share with then  lists of fake AV pages we discover with Google as we find that they do not block them 100% of the time.

Let's look an one example. The terms "marisol terrazas" was very popular on May 19th (she's a singer in the band Los Horoscopos de Durango who got married that day, apparently). On the first result page, all links are malicious! They all redirected to a fake AV page. But Google shows a warning for only two these links. Worse still, my antivirus plugin shows all of them as safe!

All the links of the first page are malicious!

Fortuantely, 4 these links are currently down. The 6 other links lead to fake AV pages on two different domains: www1.bestdefender-51p.xorg.pl and www1.bestdefender-68p.xorg.pl. Neither Google SafeBrowsing on Firefox nor SmatScreen Filter on Internet Explorer 8 blocked any of these fake AV pages.

Your antivirus will very likely fail you again when the malicious executable file is downloaded: only 12 out 41 AV vendors find anything malicious, which is still better than the 9 out of 41 I saw earlier, or even 2 out of 41 not long ago.

The two malicious domains have been reported to Google and should be blocked on Firefox and Chrome at this time.

If you do the same search on Bing, none of the links within the search results are malicious.

-- Julien

Spike of "iepeers.dll" exploits

We have seen a spike in exploits using  the CVE-2010-0806 "iepeers.dll" vulnerability since this past weekend. The vulnerability affects Internet Explorer 6 and 7.

We have seen this exploit in the wild since that day, usually a few times a week. However, this past weekend, we witnessed a spike of several hundreds exploits a day. They all come from the same type of URL (hxxp://1269754898890.9934.eu.tv/mm/index.html) with different numbers for the sub-domains. The content of the malicious pages is exactly the same.

The code is well obfuscated - it is split between several files, uses eval, DOM references, and exceptions (try ... catch). From the information I could gather, the exploit page has been written by Chinese hackers to target Chinese users. Part of the intermediate code generated is written with Chinese characters. Samples of the exploits have been reported in a couple of Chinese forums. It seems that users get redirected to the exploits from other websites, mainly though hacked sites.

Here is what the original source code looks like:

Source code of the "iepeers.dll" exploits used in recent attacks

The page does not require any user interaction. The exploit runs as soon as the user gets redirected to this page.

-- Julien

CVE-2010-0806 Exploit in the Wild

CVE-2010-0806, a use-after-free vulnerability in the Peer Objects component, was announced in mid-March 2010. The vulnerability impacts Internet Explorer 6, 6 SP1, and 7 - a patch was made available by Microsoft in the MS10-018 security update last week. Zscaler received early notification of the vulnerability through our trusted partnership with Microsoft and was able to deploy signatures to detect and block exploit attempts soon after the public release of the vulnerability.

Today this site was detected and blocked for attempting to exploit CVE-2010-0806:
hxxp://cn.cnsa56.info/w/woz.htm
--> and supporting script: hxxp://cn.cnsa56.info/w/k.js

The JavaScript used to exploit the vulnerability is heavily obfuscated,
And the script contains some try-catch statements to evade detection and some automated analysis tools,
and
The above try{} statements will fail, so the code within catch{} will be run, which defines some variables and logic for decoding the above shellcode.

Wepawet fails to decode/analyze properly, and categorizes the URL as benign. VirusTotal has 2/39 Anti-Virus engines that detect as a suspicious JavaScript downloader through their heuristic engines.

After decoding and analyzing the shellcode, it downloads the payload:
hxxp://v.vkjk6.info/w/win.exe

Unfortunately, VirusTotal shows no detection for this file. When conducting basic analysis on the binary payload, it becomes obvious that this is not a valid PE executable. It is likely that the binary is encrypted or obfuscated and that the shellcode run from the CVE-2010-0806 exploit will decode the binary on the victim's machine. (I will run the exploit in a sandbox, and post any follow-on analysis of the payload).

Often times, the domain information for malicious domains is masked through a domain privacy service (like Domains by Proxy)- however, this was not the case for the domains involved in this attack.

Here is the billing information for the cnsa56.info domain:
This same registration information was used for another live domain: ac364.info

And for vkjk6.info:
126.com is a free email provider,

The registration information, email provider used, and variable names used in the attack indicate the attacker is a Chinese speaker and possibly of Chinese nationality.

Microsoft Internet Explorer dips below 70% market share

I ran across this article by Net Applications that shows their recent browser tracking data. According to their stats, Microsoft Internet Explorer (MSIE) browser has finally dropped below 70% of the overall browser market share, and Firefox has risen above 20%.

Overall, this is nice for Firefox and alternative browsers, but it does have both positive and negative security implications. For a period of time, it felt like the world wide web was a homogenous environment of MSIE browsers everywhere (and before that, it was Netscape browsers). Now we're finally at a point where the numbers may start supporting the notion that we have a true heterogeneous environment blossoming. Heterogeneous environments, whether it be a computer network or a biological system, are often much more robust and stable than a homogeneous environment simply because a homogeneous environment is susceptible to a single incident (such as an eruption of a pathogen, or a browser exploit in our case) wiping out the entire environment in one fell swoop. So the growth of browser alternatives is actually good for web browser security overall, because it means not all systems will be p0wn3d by the next devastating MSIE vulnerability.

There is also a downside of this too. With the rise of active use of alternative browsers, there is now enough incentive for attackers to take the time to attack/exploit the alternatives. We kind of already knew this, and it was largely already happening in the real world, but the numbers help to support the idea. Simply put: if no one is using a browser, there isn’t much blackhat value in finding a vulnerability in it to exploit...you’d essentially have a specialized weapon with a lack of targets to use it upon. But once there is a moderate/sizable population of those targets, the effectiveness of that specialized weapon (i.e. exploit) increases. We’ve seen this before with the Apple Mac platform: many people claimed it was more secure than Windows because it had fewer publicized security vulnerabilities. There's even the claim that Macs don't need anti-virus software because there are no viruses for Macs. Of course, Mac popularity grew, the number of deployed systems rose, and that caused the attackers to take notice. Now we have active research and exploitation of OSX and its components, and a host of malware specific to the Mac platform (for the skeptical: OSX.Leap.A, OSX.Exploit.Launchd, OSX.Macarena, OSX.Inqtana.A, etc.)

Overall this is the right direction for things to be heading. However, those trying to fly under the blackhats' web exploitation radars by using an alternative/obscure browser may find their days of obfuscated safety are numbered. As soon as the obscure browser you are using jumps into the limelight, attackers are sure to pounce on it eventually as well.

Side note: I've encountered many individuals that have employed this 'security through obscure browser' tactic. The issue is that they were using browsers like Maxthon, NeoPlanet, Avant, etc. What they didn't realize is that all of these browsers were just different UI shells on top of the MSIE web layout engine (called 'Trident'). In other words, they often just as vulnerable as if they were directly running MSIE—there was no security advantage gained. Overall there currently four major web browser 'engines': Trident (MSIE), Gecko (Firefox), WebKit (Safari), and Presto (Opera). Most browsers on the market today use one of those engines (or a derivative), and that means any vulnerability that affects the engine will affect any browser built upon it. So you might hear of a vulnerability in Firefox, but the bug could truly be in the Gecko engine and thus other browsers like Flock, Camino, Epiphany, Galeon, SeaMonkey, and Songbird (all Gecko-based) could be vulnerable as well. Therefore if you are looking to differentiate yourself by using an obscure browser for security purposes, you should do some research to ensure the browser you are running is not running the same (vulnerable) web engine as the more popular browsers.

Until next time,
- Jeff