Facebook Scam for Stalkers

If you are like me, you might feel bad about leaving your dog home alone all day while you are at work.  So to alleviate his boredom, I've let him sign up for his own Facebook.  Being new to the social media scene has already resulted in one tragedy. Well, my dog has done it again.  This time he was paranoid over whether his girlfriend from across the street was cheating on him.  So of course when he sees the new FBStalker26.com, he must try it.

On Version 26! So Advanced. So Legit.

Being a human, I know that this is obviously a phishing attempt trying to trick my dog into revealing his username and password to Facebook or worse.  Usually a Facebook scam's success is determined by the paranoia of who is looking at your profile or how many free iPads you can win.  Once you realize that, these phish attempts are almost elementary to recognize.

Always look at the address bar before entering your creds.

 The link from that photo will take you immediately to a new page where you are meant to log in again with your Facebook credentials.  A quick glance at the address bar will show you that you are not in Kansas anymore.  Don't do it!  Don't enter that information!

Oh no you did it...Now your username/password have been compromised, they still won't have an easy time into your account due to higher security policies from Facebook.  Unfortunately, my dog was gullible enough to enter in his security question and answer, only to be disappointed by a 404 error immediately after that entering his data.  Looks like he'll never know who is stalking him now, but don't worry...he won't have access to his own Facebook account for much longer.

Introducing ZAP

Access ZAP - http://zap.zscaler.com

View a video walkthrough for ZAP

ZAP Home Page

After many months of hard work by the ThreatLabZ Team, I'm very pleased to unveil ZAP (Zscaler Application Profiler). ZAP makes it easy for anyone to determine the risk posed by a given mobile application. Users can do this by either looking up past results, or more importantly, proactively scan any iOS/Android app.

Why did we build ZAP? Being a inline security solution inspecting web traffic, it's imperative that we're able to not only analyze traditional web traffic, but also web traffic sent by mobile applications. While we think of mobile apps as native software, in many ways they behave like custom web browsers, leveraging HTTP(S) for communication. We therefore started building ZAP as an internal resource to analyze mobile app traffic, but quickly realized that people are all too trusting of mobile apps downloaded from an 'official' app store. Leveraging ZAP, our research has shown that apps commonly expose privacy and security risks from sending passwords in clear text to sharing personally identifiable information (PII) with third parties and that's why we're also releasing a public version of ZAP - to empower people to see this for themselves.

Search

The easiest way to leverage ZAP is to search through the historical results. Simply by typing the name of a mobile application in the search field, you can see if it has previously been analyzed. To further refine your search, you can additionally include the OS name (iOS or Android).

Sample ZAP Search Results

In the sample results above, you'll note that the application receives an overall score out of 100 with high numbers representing a greater security/privacy risk. Detail is also provided on the following four categories which influence the overall score:

• Authentication - Username/password information sent in clear text or using weak encoding methods
• Device Metadata Leakage - Transmission of device information such as the UDID (Unique Device Identifier), MAC address or details about the operating system
• PII Leakage - Sharing personally identifiable information such as phone numbers, email addresses, mailing addresses, etc.
• Exposed content - Communication with third parties such as advertisers and analytic firms

Scan

The true power of ZAP comes from it's ability to empower anyone to capture and analyze the web traffic from a mobile application. In order to accomplish this, we leveraged an excellent web proxy known as mitmproxy, built a front end to interface with it and created engines to automatically analyze the captured traffic to hilight security/privacy issues.

Scanning an application is as simple as pointing your phone to ZAP and using the application that you want to analyze - that's it. View the video below for a detailed walkthrough of the scanning functionality, but overall, it's a simple six step process as noted in the image below.

Video

The video below provides a detailed walkthrough of all ZAP functionality.

We look forward to hearing your feedback on how we can continue to improve ZAP, so please take it for a test drive and let us know what you think. There are many mobile apps that expose users to security/privacy risks and to date, the app store gatekeepers aren't doing an adequate job of protecting end users from these threats. Using ZAP you can help analyze the ever growing list of mobile apps and reveal those that are putting users at risk.

Enjoy!

- michael

London Olympics: Stay away from scams, data theft and phishing

The Summer Olympics in London have kicked off and cyber criminals, spammers and data thieves are wasting no time, capitalizing on Olympic related scams.  Currently, the volume of websites selling bogus Olympic tickets are on the rise. These sites normally propagate their campaings though unsolicited ad banners, popups, social networking sites and email messages. Let us examine one such site in detail.

This bogus site is liveolympictickets(dot)net, which also has a Facebook page as shown below:

The website claims to sell official tickets for the London Olympics. As you can see from the screen shots below, they have tried to retain the same
aesthetics as the official London 2012 site: [http://www.london2012.com/].  This bogus site allows you to add items to your shopping cart, checkout and pay using a credit card. It works just like any other normal ecommerce website.

The site also has external links which redirect to other websites that have the same kind of bogus tickets offers. Some of these sites include pay-per-click scams.

Let us try to examine what is happening in the background. When you type in your personal details such as email, address, phone no. etc., they get sent via plain text (no encryption). The same applies when credit card details are sent, exposing them on the network.

These websites do not have adequate security mechanisms in place, visiting and entering private information could lead to information leakage/theft. This website is just a needle in the haystack. There are numerous such sites which try to market fake promotions/live streaming/tickets. 


Stay away from these websites. The official London Olympics site maintains a list of websites which are known to sell fake tickets, check them before buying any tickets: [http://www.london2012.com/spectators/tickets/ticket-checker/]. 

If you are concerned about the legitimacy of a website, Zulu, Zscaler's cloud based URL risk analyzer can be used to check for malicous/spam/phishing sites etc. Visit [http://zulu.zscaler.com] for more Information.

Facebook Likejacking, phishing and spam

Last Thursday, I wrote about Facebook Likejacking. Today, similar pages were brought to my attention. They use Likejacking to spread through user profiles using much more aggressive spam techniques.

The pages looks like they come from Facebook. The teaser is a video that should be watched "only if you are 16 or older". The play button hides a Facebook Like widget.

Spam page looking like Facebook

Before the user can play the video, he must either verify that he is at least 18, or that he is a human ... by filling out surveys, trying games, etc.! The spammers are paid for each action taken by the user (PTC campaign).

"Security check": the user must fill out a survey

If you stay on these pages long enough, they will attempt to send a form on your behalf. Fortunately, Firefox throws a warning.

Firefox prevent the automatic POST

acidattacker.com shows a Facebook page and a Youtube page with the same content.

Fake Youtube page from spammers

These spam pages can be found at:

• hxxp://bnltwo.info/video2/
• hxxp://acidattacker.com/

-- Julien

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

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.

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:

• The presence of a backdoor that may allow anyone to control the site, as shown in the "Hot Video" pages: analysis of an hijacked site (Part III) blog;
• Spam SEO pages;
• Identified JavaScript/HTML injection;
• and more.

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 http://compromised.example.com/ 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 http://fake.example.com/ 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 jsobrier@zscaler.com. This plugin is a nice addition to our Search Engine Security (SES) add-on to keep consumers safer online.

Shop Safely!

-- Julien

SSL: the sites which don't want to protect their users

Last week I explained some of the challenges that websites face to switch to SSL to protect their users. The main challenge is to send the correct SSL certificate in all cases.

Some websites make it very hard, or even impossible, to use secure connections to protect their sessions. It has been exactly a month since Firesheep was released to demonstrate the problem of session side-jacking, but these websites are still not willing to do anything about this problem.

Here are some of these sites, all part of the list of domains monitored by Firesheep.

Amazon: no HTTPS for you!

It is just not possible to use https://www.amazon.com/! This address redirect users to http://www.amazon.com/.

Permanent redirection from HTTPS to HTTP

To their credit, users must login again over HTTPS to make an order, but Amazon still provides plenty of information about their users: first name, last name, what they're interested in, full access to their shopping cart, etc.


Basecamphq.com: 37signals.com certificate

If you go to https://www.basecamphq.com/, you get a certificate for 37signals.com.  This isnt very helpful for users not aware that BaseCamp is a product from the company 37Signals.

SSL certificate valid for a very different domain name

Facebook: hidden HTTP connection, HTTPS login fails

I logged into my Facebook account using https://www.facebook.com/. Out of the 10+ requests required to display my home page, one of them is done to http://www.facebook.com/ap.php. This request does carry all the cookie values needed to hijack my account. There is currently no way to surf Facebook safely.

Unsecure HTTP connection

There is a worse scenario. I logged out of my account, and went to the secure login page https://www.facebook.com/. I entered the wrong password by accident. I was then redirected to the secure page https://login.facebook.com/login.php. There, I entered my password correctly. But I was redirected to the unsecured http://www.facebook.com/home.php (no HTTPS)!

Redirection from secure login page to unsecured home page

Although Firesheep has made a lot of noise, and the issue of session side-jacking has now been widely reported on, even the major sites have not taken the necessary actions to protect their users. It is very sad to see sites such as Facebook, widely used and by a large and diverse audience, are still very insecure.

This was just a quick review of a few sites, I'm sure plenty of other sites have the same weaknesses.

Happy Thanksgiving!

-- Julien

Which networks are more susceptible to Firesheep (aka session sniffing)?

Firesheep highlighted once more, the problem of session sniffing. Users on open wireless networks are especially at risk when they login to websites without SSL encryption. But not all wireless networks are the same when it comes to sniffing traffic...and wired LAN networks are not 100% safe either.

Firesheep found user sessions

Wireless networks

Firesheep was released to demonstrate the inherent weakness that session hijacking can present on wireless networks. They are several types of wireless networks, some are safe, but most are susceptible to session theft.

Open networks

Open wireless networks are becoming more and more popular. They can be found in public libraries, coffee shops, book stores, etc. Anybody can connect to these networks and no password is required. An attacker simply needs to be physically close enough to the wireless signal to steal unencrypted sessions.

WEP

WEP networks are protected by a password. These networks are often used in hotels to restrict Internet access to paying customers, but the password is the same for everybody. If the attacker knows the password, the network is as unsafe as an open wireless network.

It's generally very easy for an attacker to get the password without being a real customer (just ask another user for the password and you will likely get it). However, knowledge of the password is not necessarily required, as WEP encryption has been broken. There are tools freely available to crack the password.

WPA-PSK/WPA2-PSK

Unlike WEP, WPA negotiates a different key with each client to encrypt the traffic, but like WEP, WPA/WPA2 PreShared Key (PSK) encryption has been cracked as well. Somebody with enough security knowledge can determine the shared key, and sniff the HTTP sessions.

WPA-Enterprise/WPA2-Enterprise

These extensions built on the WPA/WPA2 protocols have not been cracked. Unfortunately, those are not often found or personal wireless equipments.

Wired networks

Wired networks are not necessarily safe. As with a wireless network, the type of technology used has an impact on the likelihood that traffic can be intercepted.

Hubs

If hubs rather than switch are used to connect computers, session sniffing is easy. Hubs send network traffic received on one interface to all other interfaces. This means that anybody connected to the same hub receives everyone else's traffic. Hubs are not used in many enterprises because of the security issues they represent, as well as their performance issues. However, they are cheaper that switches, and thus, can still be found in home or SMB networks.

Hub: traffic is replicated to all ports

Switch

Switches are more efficient than hubs: the network traffic is forwarded to one interface only. In theory, session sniffing is not possible on these devices. However, it is quite trivial flood a switch in order to make it behave like a hub. This flooding would probably be noticed in a company with a good IT department monitoring the internal network, but not necessarily in smaller companies.

Switch: traffic is forwarded to one interface

Monitor port

Most enterprise-grade network equipment (switches, routers, firewalls) has a monitor or mirror port: all traffic seen by the switch is mirrored to this interface. Anybody with physical access to this port can sniff traffic from the entire network. Unlike the case of flooding a switch to make it behave as a hub, this would not create any unusual network activity, and could not be detected.

Don't trust your network! Wired LANs are safer than wireless networks in general because they require physical access, but they are not 100% safe. To be sure that you're the only one accessing your accounts on the web, make sure you use SSL: use HTTPS only, or use an SSL VPN.

-- Julien

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

BlackSheep for Linux

BlackSheep uses compiled code to listen to HTTP traffic. These executables come straight from Firesheep. Firesheep ships with executables for Windows And MacOSX 10.5 (Intel) only, this is why the first release of BlackSheep supports these 2 platforms only.

The number one request I got was to support Linux. The good news is that it is now possible to run BlackSheep on Linux - though it does requires some work to setup.


Too Many Linux environments

The main challenge is that the back-end must be compiled on each possible environment: CPU (x86, x86_64), compiler (gcc 3, gcc 4), and also different versions of libpcap, etc. In the case of Firesheep and BlackSheep, it is not possible to deliver one add-on that would work on all Linux environment.

This means that each Linux user must compile their own version.


Requirements

To make your own Linux version of BlackSheep, you need:

• autoconf 2.61 or higher (autoconf -V)
• libpcap-devel with pcap-config
• xulrunner-sdk (or xulrunner-devel depending on the distribution)
• boost-devel

Here is how to proceed on CentOS.

autoconf 2.61

CentOS provides autoconf 2.59, so a new version must be compiled from source:

wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
tar xf autoconf-2.65.tar.gz
cd autoconf-2.65
./configure
make
sudo make install
autoconf -V

If autoconf -V still shows the old version, modify your PATH:

export PATH=/usr/local/bin:$PATH

libpcap-devel

The version of libpcap-devel in CentOS is too old. A new one must be installed from source:

sudo yum install flex
sudo yum install byacc
wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
tar -zxvf libpcap-1.1.1.tar.gz
cd libpcap-1.1.1/
./configure
make
sudo make install

boost-devel

sudo yum install boost-devel

Back-end from Firesheep

Then, you need to compile the Firesheep-backend. Get the source code for Firesheep for Linux:

sudo yum install git
sudo yum install xulrunner-devel
git clone git://github.com/mickflemm/firesheep.git
cd firesheep
git submodule update --init
./autogen.sh --with-xulrunner-sdk=/usr/lib/xulrunner-sdk-1.9.2/
make

Note than xurlrunner could install in a different folder on your Linux box, for example in /usr/lib/xulrunner-devel-1.9.2.12

Check if the back-end works correctly. The directory might be slightly different

cd xpi/platform/Linux_x86-gcc3/
sudo ./firesheep-backend --fix-permissions
./firesheep-backend --list-interfaces

The last command might generate an error. However, this may not be an issue. To check if the packet capture works, try this (you may want to change eth0 to wlan0):

./firesheep-backend eth0 "tcp port 80"

In a different console, try this:

wget http://www.zscaler.com/

You should now this this in the first console:

./firesheep-backend eth0 "tcp port 80"
{"from":"10.10.100.109:37753","to":"72.249.144.174:80","method":"GET",
"path":"/","query":"","host":"www.zscaler.com","cookies":"",
"userAgent":"Wget/1.11.4 Red Hat modified"}

Congratulations, you'll be able to run BlackSheep on your box.

Next, you need to include the new back-end in the BlackSheep plugin (1.3 or higher):

cd ~
wget http://www.zscaler.com/research/plugins/firefox/\
    blacksheep/blacksheep-latest.xpi
mkdir blacksheep
unzip blacksheep-latest.xpi -d blacksheep/
cd blacksheep
cp -r ../firesheep/xpi/platform/* platform/

Edit the file install.rdf Remove the following lines:

[em:targetPlatform];Darwin_x86-gcc3[/em:targetPlatform][em:targetPlatform]WINNT_x86-msvc[/em:targetPlatform]

or add your new platform:

[em:targetPlatform>Linux_x86-gcc3</em:targetPlatform]
[em:targetPlatform]Linux_x86_64-gcc3[/em:targetPlatform]

You may also want to disable the updates to keep your custom, stable version. Remove this line, or modify the URL:

[em:updateURL]http://codebutler.github.com/firesheep/update.rdf[/em:updateURL]

You can now create the XPI file:

zip blacksheep-latest-linux.xpi -r *

Now, install BlackSheep. Restart your browser and open blacksheep/blacksheep-latest-linux.xpi.

There is one last step: the permissions must be fixed on firesheep-backend.

cd .mozilla/firefox/ygqde9s7.default/extensions/\
    jsobrier\@zscaler.com/platform/Linux_x86-gcc3/
sudo ./firesheep-backend --fix-permissions

The new version of BlackSheep contains Linux versions built on CentOS5 x86 and x86_64. If this does not work in your environment, follow the procedure above.

-- Julien

Update to BlackSheep

First of all, thank you very much for all your e-mails and comments! I've tried to answer all. I will give the answer to the most common questions in this blog post.

BlackSheep 1.1 is available. It fixes one issue: with HTTP requests spread over several packets, BlackSheep could detect itself as Firesheep. This is now fixed. To get the new version, go to Tools - Add-ons - Extensions and click on Find Updates. A new version of BlackSheep should be found. if the regular update dopes not work, install it by clicking on this link.

Some users reported the same issues or comments. I'll try to answer them in this post.


Cannot install

BlackSheep cannot be installed in this environment

If you get an error message similar to this one ("BlackSheep" could not be installed because it is not compatible with your Firefox build type (Linux_x86-gcc3). Please contact the author of this item about the problem.) when installing the add-on , this is because your version or Operating System is not compatible with BlackSheep. BlackSheep works on Windows (XP or higher) and MacOSX (10.5 or higher, Intel processor only), and Firefox 3.5 to 3.6.12.

The main reason for these restrictions is that BlackSheep, like Firesheep, contains executables to listen for HTTP traffic. These executables must be compiled for each platform they run on. BlackSheep's executables come straight from the Firesheep code.

However, I am working on extending the platform that can run our plugin. Here are the 2 platforms which should be supported soon:

Firefox 4.0 Beta

In theory, BlackSheep should work on Firefox 4.0. However, I don't have the latest beta installed for testing. If Firefox beta users are ready to test the plugin, I can send them a special package. if enough readers test the plugin successfully on Firefox 4.0 Beta, I will make the official version available for 4.0 Please e-mail me to jsobrier@zscaler.com if you have some time for testing.

Linux

Support for Linux is quite a challenge. As mentioned before, the main problem is that there should be a different version for each Linux distribution out there because of the dependencies on multiple libraries.

But support for Linux was number one request I got in the mail today, so I have spend some time on it. Support for Linux should be available on Wednesday. I'll announce it on this blog. Be aware that this will involve some work form the Linux users to get BlackSheep running in their environment.


Javascript error in the preferences menu

JavaScript error in the Preferences menu

"ReferenceError: Cc is not defined". This problem happens mainly for Windows users. Make sure you have Winpcap installed. If not, install it and restart your browser.

Apparently, this also happen for a few Mac users. The main reason is that the back-end is not able to retrieve the list of network interfaces. However, the plugin would most likely work if the interface were to be hard-coded in case of failure. I'm working on a fix for this.


MacOSX and FileVault

If you use FileVault on MacOSX, you might be prompted for a password to run firesheep-backend. See this thread for more information.

Enjoy BlackSheep, and keep reporting any issues or comments.

-- Julien

"Spyware and Virus free" - Really?

Most of the non-malicious spam that we see in search results relates to fake search engines. The operators of these sites make money by tricking users into clicking on disguised advertising. Another way they make money is to convince users to install adware onto their computers as they will then receive a fee from the adware vendor.

For example, LoudMo is a well-known adware vendor. Their affiliate network pays $1.50 per installation.

 LoudMo's adversting on their main page

Spammers don't hesitate to trick users into downloading such adware. They hack legitimate web sites to pollute Google search results, and then redirect users to fake video pages.

Fake video

Clicking on the "video" (actually a simple image) warns the user that the "Latest version of FLVDirect Video Player not found! Click OK to install the FREE FLVDirect Video Player latest version."

Prompt to download a video player

The user gets redirected to an external site where he can download the video player. This player is guaranteed "spyware and virus free".  This does not mean adware free! 20 antivirus vendors find something dangerous about the executable, 5 flag it as an adware.

Guaranteed "spyware and virus free"!

-- Julien

Those who know where and when you surf

Nobody likes the idea of a big brother watching over them as they surf. Yet as browser technology evolves, we are starting to have some privacy-violating "byproducts" of innocuous features. Now, we already generally accept that our immediate/upstream Internet providers can possibly snoop on our traffic—they can see what sites we try to access (whether by IP destination or monitoring DNS queries) and can peek into plaintext content. But the ability for an ISP to monitor traffic is limited to only the traffic that passes through it—namely, its customers. What if there were central organizations that could monitor user traffic (to a certain degree) across any/all ISPs?

I'm going to go ahead and overlook the obvious companies/services where you install a toolbar into your browser so they can watch and tabulate everywhere you go (like Alexa). That is an opt-in situation where you willingly give all your info to a third party. I'm also going to overlook any web proxy services that you might be using, because those are also opt-in situations with the same ramifications. And of course, any internal monitoring within an organization is also exempt; I want to focus on who, outside of your local network, organization, and your ISP, is receiving your surfing data without you explicitly opting-in to give it to them.

So let's start with HTTPS, as implemented in common web browsers. Most common browsers include certificate revocation checking capabilities for ensuring an HTTPS site certificate hasn't been compromised. When you access an HTTPS site, the browser will receive the server certificate and run off the to the designated CRL and OCSP servers to query whether the certificate has been revoked. Those CRL and OCSP servers are operated by the certificate issuers, such as Thawte, Verisign, etc. The key here is that many SSL certificates have a one-to-one relationship with a specific web site (i.e. traditional certificates and not wildcard certificates); so a query to an OCSP responder for a web site certificate essentially tells the certificate issuer that you are in the process of accessing that site. Now, certificate issuers can only track accesses to sites they issue certificates for—but in 2007, Verisign and subsidiaries were deemed to have issued over 57% of the SSL certificates in use, giving them the theoretical capability to track site access to over half of the HTTPS sites on the Internet.

Fortunately none of the OCSP responders I briefly reviewed set HTTP browser cookies, which means they are not tracking unique individuals (at least, not through simple browser means). That is a good thing; the best tracking granularity they can achieve is generally per source IP address (ignoring browser header/request and TCP protocol fingerprinting to differentiate different browsers/systems from the same IP). This can be problematic if you're a home user and have a one-to-one relationship with your IP address, but tolerable if you're behind a NAT or proxy that serves many users (giving it a many-to-one relationship with the IP address). [Aside/favor: If you happen to see a public OCSP setting browser cookies, let me know!]

Default browser start pages are another privacy leaking avenue. Every time you start your web browser, Microsoft, Apple, Opera, or Mozilla hears about it through the various default browser start page request(s):

http://en-us.start2.mozilla.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
http://www.apple.com/startpage/
http://portal.opera.com
http://go.microsoft.com/fwlink/?LinkId=74005
http://runonce.msn.com/runonce3.aspx

The start pages themselves may seem innocuous, but they can chain to more exposure. For example, Apple's start page includes a request to metrics.apple.com, which is really a pointer to Omniture (resolving metrics.apple.com returns a DNS CNAME to appleglobal.112.2o7.net); the request collects and sends a lot of identifying browser information including screen resolution and all installed browser plugins. I've seen occasions where responses to metrics.apple.com forward to Doubleclick.net too. Now, sure, it's common for web pages to include metrics/analytics and advertising links—but such elements on browser start pages means these syndication/service providers also have access to realtime information of when you start your browser. In addition to Apple's use of Omniture and Doubleclick, Opera's portal page includes resource links to Google Analytics, and Mozilla redirects to Google. Microsoft's portal page used Webtrends.com for metrics.

But more importantly, can any of these providers uniquely identify you? Microsoft relies on m.webtrends.com, and that site sets a unique cookie for you--so Webtrends has the ability to track you no matter where you go. Ditto for Apple, Omniture, and Doubleclick. The fact that these metric and advertising elements are hosted on browser start pages means the services have the opportunity to plant their unique cookie right at the beginning of your surfing session. Plus, look at where and how the start pages are hosted. Microsoft redirects from Microsoft.com to MSN.com, where the start page actually lives. By placing the start page on MSN, all of the MSN cookies are now available--and if you are logged in, that means Microsoft knows who you are and can individually identify you if they so choose. Since Mozilla redirects to Google, the same case generally applies to Google using its own cookies to identify/track you.

But fortunately this is only a minor information exposure; knowing you started your web browser is not exactly an earth-shattering privacy violation, and it only occurs at the very beginning of your surfing session (not when you open a new tab, etc.). Plus, this immediate information doesn’t expose where you actually wind up surfing to...just that you opened a browser. The previously mentioned OCSP issue reveals far more information regarding where you are surfing; but it is not the only feature that does so...

Many browsers have recently added various anti-phishing and safe surfing features which essentially query the host/URL you are accessing in a database to see if it's a known offender and thus should be blocked. Think about that for a second: for every URL/host you visit while surfing the Internet, a lookup is done to ensure the URL is safe. So how is that lookup being done?

Some of the browser vendors have designed their features so that databases of the known offenders are downloaded and stored on the user's local system, so they can be queried locally. This is ideal, as it means the lookups are fast (just look inside the downloaded file) and it doesn't expose the lookups that are actually occurring. However, note that I began this paragraph with the term "SOME of the browser vendors"...

It turns out the biggest questionable privacy offender is Opera. Their SiteCheck function, enabled by default and meant to warn you when you try to access a malware site, sends a real-time request to sitecheck2.opera.com for every new host you surf to. The transaction looks something like:

GET /?host=www.google.com&hdn=naLWSHPy7ud1pACYor32hg== HTTP/1.1
User-Agent: Opera/9.64 (Windows NT 5.2; U; en) Presto/2.1.1
Host: sitecheck2.opera.com
...

HTTP/1.1 200 OK
Date: Fri, 15 May 2009 15:17:11 GMT
Content-Type: text/xml
...
<?xml version="1.0" encoding="utf-8"?>
<operatrust version="1.1">
<action type="searchresponse">
<host></host>
<ce>14400</ce>
<w>1</w>
</action>
</operatrust>

That means Opera hears about every web site host you access, and can keep a historical record if they really wanted to. Now, the SiteCheck queries are not utilizing cookies to track individual users, so tracking granularity is limited to per-source-IP resolution. But it's still a notable privacy exposure. Other browser features like IE8's Suggested Sites likely expose the same level of information, but I have not confirmed it personally (but their level of privacy warnings and opt-in requirements seem to suggest so).

So now that we've gone through all of that, what can you do about it? Well, the good news is that you can generally turn off all of the above mentioned behaviors (you'll have to dig around in the Advanced Configuration areas of your browser)...but you might not want to. Sure, you can change your browser start page to something else without ramifications (actually, if you change it to a blank page, you'll find your browser starts faster because it doesn't have to initially load an external page). But OCSP checking and SiteCheck features are security protections that actually help keep you safe--so by turning that stuff off, you are opening yourself to more risk. So you need to decide what’s more important to you: your security, or your privacy.

Happy deciding,
- Jeff

What did you do on Data Privacy Day?

January 28th is officially international Data Privacy Day. Apparently this was established in 2008 to raise awareness for data privacy issues, provide education (particularly to teenagers) regarding data privacy concerns, etc. Did you even know about it? Don't worry, neither did I. Maybe we need an awareness campaign to educate people that there is an awareness campaign to educate people (heh). Intel has some various online links and material related to the happenings of Data Privacy Day.

Anyways, while educating users to not hand out their personal details is a good thing, the bulk of concerning data privacy breaches have been largely caused by large corporations mishandling user data. Whether it's AOL, Choicepoint, or Heartland, educating a user to keep their data private is irrelevant if a 'trusted' third-party data keeper is just going to expose it on their behalf. Thus I'm not sure why we are trumpeting to solve privacy at the end user level with new 'privacy enhancing technologies' (PETs) when bigger data privacy and exposure problems exist upstream. P3P headers, anonymizers, and cookie removers are not going to affect things like the Veteran Affairs leak from happening. Even if I'm tight-lipped about my personal details, my service provider might not be. Or the person my service provider outsources to might not be. Or the person that person outsources to might not be. You get the point.

I'm sure there are some in the crowd that are thinking "PCI will help with data privacy exposure issues in third-parties." Well, kind of. Just look at Heartland--they were PCI-compliant. Which brings to an interesting point: compliance != security. PCI can potentially ferret out gross negligence, but catching all the low-hanging fruit doesn't prevent someone from going a little higher up the tree. Especially if they are hungry.

Until next time,
- Jeff

The Obfuscated TCP project

Hello, Jeff Forristal here. In my last post I talked about the desire of some folks to use SSL for encryption purposes but forego the authentication components (via the use of self-signed SSL certificates). Overall it’s not a very good idea, since removing authentication from the process renders the benefit of the encryption moot for all but the most trivial (and lazy) threat vectors (passive eavesdropping).
So earlier this week I ran across a mention of the Obfuscated TCP project (a.k.a. ObsTCP), developed by Adam Langley of Google. The project is self-described as:
Obfuscated TCP is a transport layer protocol that adds opportunistic encryption. It's designed to hamper and detect large-scale wiretapping and corruption of TCP traffic on the Internet.
This sounds like an ideal potential alternate for all of those who wish for an 'encryption without (expensive public CA certificate-based) authentication' solution. The ObsTCP idea is simple: use light-weight and fast encryption functions to obfuscate all TCP data streams, in an effort to thwart passive eavesdropping. Processors are fast enough these days that the additional overhead to perform the data obfuscation is negligible. And (from my interpretation of the project’s documentation), the idea isn’t to be cryptographically secure transport and/or replace SSL…it’s just to obfuscate TCP data enough to make passive eavesdropping difficult to do. We are already seeing similar approaches deployed via P2P clients to bypass ISP-based throttling based on packet/protocol inspection; the obfuscation employed isn’t robust to survive a targeted cryptographic attack, but it is enough to make high-speed protocol detection and classification difficult. The project has produced a video (hosted on Youtube) that goes over the basic goals and reasoning behind them.
Looking at the project's history, the original intent seems to be for ObsTCP to be added into the TCP/IP protocol stack (ISO layer 4) for transparency. However, apparently the ObsTCP project approached the IETF with a draft, and, ... well ..., it got a chilly reception. So ObsTCP changed gears and instead moved up the stack to the application layer (ISO layer 7), and is now focusing on HTTP as their first high-value protocol target. So the original project description of ObsTCP being a "transport layer protocol" is a bit misleading when considered in the context of the project's new implementation direction.
So how does ObsTCP work? Well, it requires an ObsTCP-capable client and server. The server admin essentially embeds the server's public key (and some meta information) in a DNS entry related to the server. The client retrieves the server's public key, opens a connection to the ObsTCP port of the server, and then uses a Diffie-Helman authentication exchange to negotiate a key to use for subsequent encryption. Right now the project is offering proof-of-concept patches for Firefox browser, and Apache and lighttpd web servers to make them ObsTCP-capable. They also offer an ObsTCP-to-normal-TCP proxy which can be placed in front of TCP services to make them ObsTCP-capable.
Overall, how does ObsTCP compare against the threat vectors previously listed in my "SSL encryption without authentication debate" post? We already mentioned that passive eavesdropping would be thwarted, as that's the purpose of ObsTCP to begin with. But what about a more active man-in-the-middle (MitM) attack? My cursory review of the ObsTCP documentation and design indicates that it does not directly mitigate that specific threat vector—however, it does make it harder for an attacker to pull off. This is because the server's public key is distributed via DNS, separate from the TCP connection. That means an attacker has to intercept both DNS request and the TCP connection in order to successfully pull of a MitM attack. Further, the DNS records can be cached at various points around the Internet, making it further difficult for the attacker to spoof a DNS response. The attacker would likely have to employ separate specific DNS attacks (such as the recent Kaminsky brouhaha) just to inject the right info into DNS in order for the TCP intercept/MitM to correctly work. The amount of effort and coordination to pull this off is far greater than a single TCP intercept/MitM attack by itself.
Overall the ObsTCP project is in alpha stages, but the idea is intriguing. It does seem to fill a need that is growing and becoming more vocalized (i.e. encryption without authentication). It will be interesting to see whether the project becomes adopted enough to start gaining public traction and attention. We figure it will be the usual circular catch-22 situation often encountered with new Internet technology: server admins forego deploying the technology because not enough clients support it, and clients forego implementing the technology because not enough servers support it. Oh well, it’s still a good idea.
- Jeff