Hauteness : The Official Haute Secure Blog

 
The official Haute Secure blog
 


You may have noticed over the last week that we have made some improvements to our Block List algorithms. After listening to your feedback over the last few months and analyzing the data from our backend scanning service, we’ve decided to make some changes. Some sites that may have been blocked in the past, are no longer being blocked.

We’ve decided to remove sites that no longer appear to be hosting malicious content from our block list. Our backend scanning system routinely checks and rechecks sites where we have found malicious content, however if no infection has been caught recently, that site will be removed from our block list. This will allow our block list to only contain malicious sites that are actively infecting people, thus not blocking on sites where we last found an infection months ago.

Why are we making these changes.

There are several reasons why a site may have caused an infection in the past, but no longer does. These include:

  • The site was hacked, but has since fixed the vulnerability and removed any malicious content added to the site

  • The site was hosting a malicious ad, which has since been detected and removed from the ad network

  • The site had malicious dynamic content added to it (think blog posting, content on a users home pages, etc.), which has since been removed

We have listened to your feedback and desire to eliminate some of the noise around sites that no longer pose a threat, thus we have implemented the above changes.

How these changes affect you.

This change only effects our passive protection, which blocks users from visiting sites on our block list. YOU WILL STILL BE COMPLETELY PROTECTED BY OUR ACTIVE PROTECTION (more details here), thus if you visit a site that has malicious content on it, and it tries to infect your machine, the active protection will protect your PC by blocking any attempts to install malware on it.

As for the sites that do get removed from our block list, our backend scanning system will continue to scan the sites, and if it finds any malicious content on those sites, the site will be re-added to the block list.

Thanks for using Haute Secure.
Rob.




 

The much awaited Service Release for Haute Secure went live a few hours ago. Those of you who already have the Haute Secure Beta installed (Build 419) should receive an automatic update notification that will point you to the install location for the new release.

 

We'll be adding some release notes shortly to the announcements forum that will list the fixes and improvements that we've made with this release.

 

We will turn off support for Build 419 in a couple of weeks, which will mean it will no longer download our list of bad sites, so please upgrade to the Service Release when you get a chance.

 

Thanks!

The Haute Secure team




 

 Hi everyone,

 

We've been very quiet on the blog over the last few weeks. That's because we've been working feverishly on a Service Release for Haute Secure that fixes many of the problems that we've seen since we released Beta 1 last month or that have been discussed in the forums. In particular we've fixed a number of crash or "blue screen' bugs that we were previously unaware of, along with some performance problems with other security products.

 

I'm pleased to say that the Service Release is almost ready - we're putting  the final touches to it right now and finishing up our testing. We expect to release it sometime next week. When we release it we'll activate the auto update feature in Haute Secure and you'll see a prompt like the one below - you simply need to click on the link for the latest available version and this will take you to our website where you can download and then install the update.

 After installing the update you'll need to reboot your PC to ensure it's properly protected by Haute Secure - we recommend you reboot as soon as you've finished the installation of the update.

 

 

 

We'll make a posting as soon as the Service Release has been posted on our website. We'll also post a list of the issues that the Service Release addresses. If you find any problems after installing the update be sure to let us know over on the Support Forums.

 Lastly thanks to everyone who reported problems via the forums and worked with us to help us understand them better. Your help has directly contributed to this Service Release - which we really appreciate.


 




 
There has been much discussion on the impact of Open Redirects with respect to Phishing. Netcraft has done a good writeup on the topic.  If you’re familiar with the problem of Open Redirects on phishing sites, it won’t surprise you to know that Open Redirects also have an impact redirecting unsuspecting users to malicious websites.

First let me define what an Open Redirect is. A Redirect is a mechanism many websites use to automatically transfer users to different parts of their website, or other locations on the internet. An Open Redirect performs the same function however does not validate the target of the redirection. This allows the arbitrary insertion of any site as the target redirection url.   

An open redirect typically takes the form http://hostname/page.aspx?RedirectUrl=http://redirectlocation/ 

Navigating to this Url would automatically redirect you to the site http://redirectlocation/ 

Why is this a problem? 

Similar to the phishing problem, Open Redirects hide the true target of a hyperlink. Suppose you go to your favorite search engine, and search on your favorite topic. In the search results, you get a link to http://www.infectionsite.com  . Most people will look at that and make a decision that there may be something bad at that site, and thus not click on the link.  

Now, malware authors know this, and thus use an Open Redirect to hide their malicious sites. 

In the above example, if you received the site http://<BigCleanWebsite>/s=http://www.infectionsite.com, where <BigCleanWebsite> is any of the big web properties online (think Google, Yahoo, Lycos, Microsoft, etc.), one may just look at the beginning of the Url, and assume they were going to a link on that “BigCleanWebsite” property. 

Taking this a step further, the above Url can be further obfuscated by Url encoding http://www.infectionsite.com,

such that the link
http://<bigcleanwebsite>/s=http://www.infectionsite.com becomes
http://<bigcleanwebsite>/s=%68%74%74%70%3A%2F
%2F%77%77%77%2E%69%6E%66%65%63%74%69%6F%6E%73%69%74%65%2E%63%6F%6D


You now have no notion that you are actually going to visit the site http://www.infectionsite.com by clicking on the link. 

Haute Secure considers Open Redirects a real threat to our users, since their intentional manipulation can cause users to make incorrect assumptions about the trustworthiness of a website which in turn can cause a user to become infected with malware. For this reason Haute Secure blocks any open redirect that we discover is being used to  surreptitiously  redirect users to infection sites. 



 
Most of today's safe browsing security products either focus on advising the user when a bad website is visited, or filtering bad content using signatures.  In Web 2.0, we do not consider that sufficient.  Any site could be an amalgamation of content from numerous dynamic sources.  And polymorphic exploit code and unannounced 0-day vulnerabilities mean sometimes signatures are too slow.  That is why Haute Secure takes a multi-layer approach that includes signature-less protection against malware installation.

Haute Secure’s initial beta release is first and foremost a behavior-based malware filter.  Haute Secure is capable of identifying and blocking the installation of malware that is delivered through exploitation of a vulnerability in the user’s browser or a browser plug-in.  This is what we term “active protection.”  Secondarily, it provides URL blocking services for known bad sites.  We call this “passive protection.”

Active Protection

Haute Secure’s active protection uses a “soft sandbox” to identify malware installation attempts.  (More information is available in a post in our forums)  This is different than a traditional sandbox primarily in that it focuses only on trapping certain violations of a behavior rule set, rather than a strict quarantine policy.  Soft sandboxing allows most normal actions during browsing to occur without interruption.  The behavior rule set triggers when behavior consistent with a transparent installation of software is observed.  While the actual rules are a bit more complicated, Haute Secure essentially looks for executable code to be installed on the computer without user consent.  Hence, if a user with Haute Secure installs an ActiveX control, this will occur without interruption.  If a user downloads and runs a program, this will occur without interruption.  However, if the user navigates to a site and the site serves exploit code to the browser that it is not properly patched again, and that exploit code tries to install malware, this will be blocked.  Haute Secure uses context clues to determine the difference between intentional and unintentional code installation.

False Positives and False Negatives

In general, the rule set is much more likely to result in a false positive than a false negative when it comes to transparent installation of malware.  (Note that the current version of Haute Secure does not protect the user if the user is duped into intentionally downloading and installing malware.)  Haute Secure’s back-end systems (which use a rule set and behavior analysis nearly identical to that on the end-user client) will rarely result in false positives.  The difference is that Haute Secure’s back-end systems run in a fully-automated fashion with a constrained set of software installed.  The most typical reason for a false positive in the end-user product is 3rd-party plug-ins in the browser.  Some of these plug-ins have auto-update mechanisms that can trigger the behavior detection.  Haute Secure’s current behavior detection works globally on the browser process.  Plug-ins that run within the browser are subject to the same behavior rules.  So, if a plug-in were to download new code and load it, this might be detected as a false positive.  The reason is that it is a violation of the primary rule:  Haute Secure blocks transparent code install.  Since the user didn’t initiate an action that caused the download (it was an automatic update feature of the plug-in), this may trigger the detection.  To address this, Haute Secure includes an Authenticode white-list.  If the update is signed by a software publisher that the end user trusts (or that is on the opt-in Haute Secure list), then the update can occur without interference from Haute Secure.  In general, updating plug-in code in-process is not ideal from a behavior analysis standpoint (it makes filtering more difficult), but it is a reality of the way that applications are programmed.


Figure 1: User-defined Authenticode white-list
As an aside, it is worth noting the importance of code signing.  Code signing (described in more detail at MSDN) can be used to cryptographically verify the publisher of a program.  While this is used by Haute Secure to a degree, in general, it is a good way to ensure the authenticity of downloaded programs.  Haute Secure code signs all components installed on the end user’s computer.


A benefit to sandboxing is that it can provide a signature-less solution.  A sandbox looks for behaviors that expose a particular intent.  As long as the behavior rule set is well constructed, the sandbox can detect attempts to exploit both known and unknown vulnerabilities.  The reason is that a sandbox isn’t looking for the exploit.  Rather, it looks for artifacts of the exploit.  That is, behaviors that are anomalous for the sandboxed program, but characteristic of what the exploit is trying to do (in the case of Haute Secure, characteristic of transparent install of new code).  In contrast, most current solutions are signature-based.  In the case of the browser, they scan the HTML, JavaScript, images, etc. that are downloaded, looking for patterns that match an exploit for a known vulnerability.  “0-day” protection on the client for most of these systems still relies on knowing that a vulnerability exists and creating a signature to detect exploitation.

Soft-sandboxing means that in general, the browser is free to do what it normally does.  Haute Secure does not provide a discardable environment, as is typical for a full sandbox.  This design decision was made to allow the user to use the browser as she normally would, with the added “active protection” to prevent transparent malware installation.


Figure 2:  Haute Secure notification that a transparent installation of code was detected

At this point, it is important to point out that Haute Secure is not really a toolbar.  Haute Secure’s toolbar is, in general, merely a notification user interface.  The core functionality of Haute Secure is implemented as a kernel driver.  While there are a few customizations in order to support a particular browser (mostly concerning context clues to filter out intentional code installs), the information collection technology in Haute Secure will work with any program.  Though it is untested, Haute Secure contains some basic templates for certain office productivity applications.  Since Haute Secure currently uses a static rule set geared towards browser protection, these templates are not enabled by default.  The current product plan includes development of these templates so that future releases can protect the user from malicious documents that exploit vulnerabilities in word processors, spreadsheets, portable document readers, etc.

Passive Protection

Haute Secure’s passive protection is based on URL or host blocking.  It is pre-emptive protection that prevents the browser from navigating to a site that is considered dangerous.  Haute Secure’s URL database contains URLs that were deemed malicious because a back-end system detected a transparent code installation attempt when navigating to the URL.  If the user tries to navigate to a site on the block list (or content is loaded from a site on the block list as a result of going to a good site), the potentially bad site is blocked and the user is alerted.

Haute Secure’s URL list can aggregate other lists, with attribution to the original source. For example, Haute Secure could incorporate phishing URLs, or URL lists that contain sites associated with known spyware companies (note that Haute Secure’s list contains sites that exploit, and if a known spyware company does not exploit a browser vulnerability on their site, it is not in Haute Secure’s list).  The initial release does not aggregate lists, hence comparison to block lists that incorporate these other types of URLs would not be 1:1.  Most functionality for incorporating 3rd-party lists is in the Haute Secure back-end, however, some URL lists are incompatible (for example, the URLs are provided as MD5 hashes of a specific character encoding of the URL) and will require updated client code for incorporation. Haute Secure has two types of notifications with regard to passive protection.  The first is an Orange notification, and second is a Red notification.  Orange notifications are associated with sites that are generally considered good by the automated back-end algorithm, but where some infection URLs were found.  When the user receives an Orange notification, the content is not blocked.  It is simply a warning that bad URLs were found in the domain.  For more information on how some popular sites make it on to the Orange list, see the writeup in our forums.


Figure 3: An Orange notification

Red notifications are given when content is actually blocked.  Haute Secure may block specific URLs (which is the case when the domain itself would produce an Orange notification), the host name, or the domain name in its entirety.  The decision on what level to block at is made by Haute Secure’s automated back-end algorithms.

Figure 4: A Red notification

When blocking URLs, Haute Secure may block the entire page, or it may block content on the page.  Haute Secure blocks the entire page (and then redirects to the Haute Secure interstitial block page) when the user navigates to a site on the block list.  Haute Secure blocks elements on the page when the page itself comes from a site not on the block list, but that loads content from sites on the block list (for example, images, ads, etc. that may be part of the displayed web page, but that come from a different site than the parent page).

Notes

Haute Secure’s current release is a beta product.  This means that users should expect some hiccups, such as issues with application compatibility, more frequent UI notifications, etc.  Haute Secure’s end product will likely have tweaks that change both the client and the back-end, resulting in a different experience than the current one.  Continued feedback from users is very important to Haute Secure.




 

stay tuned as we'll be launching our blog soon...




 

 

 

 
     


Privacy Terms of Service Give us feedback!