Tuesday, November 30, 2010

Blackhat spam SEO & Fake AV: they are still there

It's quite depressing to see that Google still contains numerous links to spam pages which lead to fake AV sites. While there are fewer of them, they are still there. This, despite the fact that attackers have not significantly changed their techniques in many months. They still hijack vulnerable sites and create spam pages with similar URL patterns. The fake AV pages are mostly the same, using the same CSS and Javascript code and antivirus engines continually fail to detect the majority of  the malicious executables.

Here is a typical example of what users will still encounter. The site casino-jugendclub.de has been hijacked to host thousands of pages like http://www.casino-jugendclub.de/lnsqo.php?page=jennifer-nettles-husband.

Primitive, but effective, SEO spam page
As usual, the page redirects real users coming from a search on Google, Yahoo! or Bing to a fake AV page. This time, the fake AV is slightly different. It mentions a "Windows Security Update", and is hosted on microsoftwindowssecurity145.com (still up at the time of writing). It looks the same as traditional fake AV sites, with animation showing an antivirus scan of the computer.

Fake AV page
And again, the detection rate amongst AV vendors is only around 25%.

Malicious executable disguised as an antivirus

Not much has changed in the past 6+ months in the world of malicious spam SEO. While Google has made efforts to combat the fake AV sites and the number of malicious spam links in popular Google searches has gone down somewhat, more needs to be done.

-- Julien

Amazon Profiles Used For Spam

Amazon's online store-front has a social networking component to it, where people with accounts can create user and seller profiles to share their interests, what they are reading, listening to, selling, etc. For the most part, anytime a site allows user-driven content to be published on the web we have seen some kind of abuse (for example, LastFM, Google Code, Adobe Groups). Amazon's profiles are no different- most appear to "profile spam" advertise various pages on the adult sites:
  • adultmediareviews.com
  • redspacetube.com
Some of the advertising language for redspacetube.com suggests illegal / child porn content. Language take from Amazon's site:

Google searches for both of the above domains show other sites hosting these similar "profile" spam advertisements. For example, Google Groups:
The redspacetube.com domain has been identified as redirecting users to Trojan malware (FakeAV) in the past (reference 1, reference 2). There are a lot of these Amazon profiles:

The Amazon profile abuse is not limited to porn and malware spam, but also includes pharma spam:
There are thousands of these profiles:
I have notified Amazon via their online abuse form and am in the process of trying to obtain a more direct contact for their abuse department.

Cyber Monday in Review

Cyber Monday is hyped every year as the largest online shopping / deals day of the year. How was your Cyber Monday? This is a short post on some of what we saw. Our perspective is from the corporate end user (i.e., people on their work computer).

During Cyber Monday, about 4% of all web transactions from our customers were to online shopping sites. To put this in comparison, during Black Friday only 2.71% of the day's web transactions were to online shopping sites. In terms of raw numbers of transactions, Cyber Monday had about 87% more online shopping transactions than Black Friday. This chart shows the magnitude of Cyber Monday online shopping from Nov. 20 - 29th.

Over 20% of the online shopping transactions for this 10-day timeframe were from Cyber Monday.

To no surprise, the web servers that saw the highest number of online shopping transactions belonged to Amazon. Here are the top 5 web servers with the most Cyber Monday online shopping transactions:
  1. (Amazon)
  2. (Amazon)
  3. (Amazon)
  4. (Akamai)
  5. (Level3)
On the Amazon netblock, the top static shopping pages viewed were:
  1. General Baby (site)
  2. General Video Games (site)
  3. General TV/Video (site)
  4. Kindle Wireless Reader Wifi Graphite product page (site)
  5. General Toys (site)
The top specific product page viewed other than the Kindle, which is on Amazon's homepage, was a TomTom GPS unit (site).

There was a decent amount of "Cyber Monday" spam advertising deals - mostly on various hardware and software. Some of which appeared to be for fake store-fronts, but most were pay-per-click affiliates. The below spam redirects the user through the adplexr.com pay-per-click site.

Get your laptops...

And cell phones...

The phishing volume seemed in range with the normal volume (reference PhishTank):
There didn't appear to be any major Cyber Monday malware campaigns or anything out of the ordinary. That being said, continue to be safe when shopping online this holiday season.

Wednesday, November 24, 2010

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

Monday, November 22, 2010

BlackSheep 1.5: more options

The latest version of BlackSheep brings new options and fixes a few bugs. I encourage all users of BlackSheep to upgrade by downloading the latest version.

Install BlackSheep add-on for Firefox 3.x

New options

Start BlackSheep automatically or manually

BlackSheep can start automatically with Firefox (as the previous version did), or manually. This allows you to use BlackSheep only when you move to a wireless network, for example.

I've changed the options slightly, for when BlackSheep actually starts. Previously, if the "check interval" value was set to 5 minutes (default value), BlackSheep would start 5 minutes after the browser was opened, and then every 5 minutes. Now, BlackSheep runs immediately, when the browser first launches, and then every 5 minutes thereafter.

A shortcut to the BlackSheep options has been added under the Tools menu for easy access.

Bookmark and installation issues

Some users have reported that the bookmarks no longer work after installing BlackSheep. This seems to be caused by external security tools (antivirus, sandbox). Disabling Sandboxie fixed the problem for one reader.

A few readers reported issues installing or downloading BlackSheep. This was caused by their antivirus engines. BlackSheep includes firesheep-backend.exe which is flagged as a malware by some vendors. This executable listens to HTTP traffic on a network interface, it is not malicious. You may need to disable your antivirus temporarily while you are downloading and installing BlackSheep.

Official Mozilla Add-ons site

BlackSheep has been submitted to the official Mozilla Add-ons site. It will likely take a few weeks before it gets approved.

Install BlackSheep add-on for Firefox 3.x

-- Julien

Wednesday, November 17, 2010

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


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.


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.


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


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

Monday, November 15, 2010

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

Wednesday, November 10, 2010

Lethic Botnet Returns, uses "Realtek" identifier

Remember Stuxnet? Chances are you do- a few months back there was a worm that spread over USB using the 0-day .LNK vulnerability (CVE-2010-2568) and targeted Siemens SCADA systems. Additionally the rootkit package that it installed was digitally signed using real certificates from real hardware manufacturers: Realtek Semiconductor Corp. (www.realtek.com.tw) was one of the companies (JMicron was the other - both are Taiwanese companies).

In recent days, I have seen malware with
Realtek Semiconductor Corp. signature information. Specifically, it has been of the Trojan Lethic / Ddox malware family. About a year ago, Jose Nazario detailed his analysis on the Lethic bot being used to spew pharma, replica, etc. spam. About a month after he posted his analysis, M86 reported on the Lethic botnet takedown. Well it appears that there is a new variant / botnet of this malware family:

Here are two recent samples:

MD5: 0460d89f0091d951184a8d77c6641340
First seen: 2010-10-31 17:42:29
VirusTotal Report

First seen: 2010-11-07 09:58:39
VirusTotal Report

Both have Realtek information reported from Microsoft's Sigcheck tool:
However, the tool shows no signer / certificate authority verified the signature. Here is a snapshot of the Stuxnet signcheck output for comparison:
Stuxnet and Lethic are completely different, and I am in no way presuming that one or more authors behind either malware campaign intersect - I did think it was interesting that this one company is being "picked" in malware campaigns though.

There may be some correlation with the exact Realtek information in the Lethic binary. The information within the Lethic binary does appear to mimic valid Realtek information for their AC97 Audio product. Doing some searches, I've found other malware families have used this exact Realtek information within their malware binaries. Here is a VirusTotal report from an SDBot sample first seen in January 2010, that has the exact same Realtek information used by Lethic. Separate malware authors could have simply selected a legitimate software package and included the exact information - however this does seem pretty coincidental. Or perhaps it could be the "signature" of a common author or group behind these artifacts - perhaps they seek to tarnish the reputation of this Taiwanese company for personal or political motivation - who knows?

There are about 91 Lethic samples with the "Realtek" signature information that Google shows from VirusTotal. These date from early September to present.

In the past few days, locations that I've seen the Lethic bot spread from include: over port 17678 over port 36182 over port 16512

The port location changes over time, and rotates through funky sounding executable names that appear to be auto-generated from various letter permutations. For example:

Following infection, connection attempts have been seen to:
izuhjsn.com ( on port 8706
xkihjhx.com ( on port 2904

The domains were both registered August 1, 2010 through the Registrars:
DomainTools shows 12 other registered domains with the "voip53" Yahoo email address and 62 other registered domains with the "dfghddf" Hotmail email address within the whois information - presumably other malicious / C&C domains.

In mid-October, an Anubis report shows a "Realtek" Lethic sample looping through a number of SMTP proxies/open-relays and sending spam similar to the pharma, replicas, etc. that Jose had reported in the previous 2009 iteration of the botnet. Here is a pcap snapshot of a replica spam message sent from the recent, Fall 2010 iteration of the Lethic bot:

El Reg recently reported on how prolific the Lethic botnet was and the success of the takedown... could it be ramping up to make a come back? Also, can this "Realtek" signature info be used to tie the author/group to the malware they have released?

The Sigcheck tool apparently parses the PE File Version Info data structure and includes this in the output. The above "Realtek" information is actually extracted from the PE File Version Info data structure (e.g., here). While this is not a digital signature- it is still identifying info that may be able to tie certain malware samples to the same author / group / or binary builder.

Tuesday, November 9, 2010

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.


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
sudo make install
autoconf -V

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

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


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/
sudo make install


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/

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

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"
"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/\
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:


or add your new platform:


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


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/\
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.

Install BlackSheep add-on for Firefox 3.x

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

Install BlackSheep add-on for Firefox 3.x

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.


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.

Install BlackSheep add-on for Firefox 3.x

Enjoy BlackSheep, and keep reporting any issues or comments.

-- Julien

Monday, November 8, 2010

BlackSheep - A Tool to Detect Firesheep

UPDATE: see the requirements for the extension at the end of the post
UPDATE: an new version is available
UPDATE: BlackSheep for Linux is available here
UPDATE: If you use FileVault on MacOSX, you might be prompted for a password. See this thread for more information.

You've probably all heard of Firesheep by now, a Firefox add-on which lets anyone hijack a user's session to various popular web applications when they're using an open wireless network. While sniffing/stealing session credentials is nothing new, Firesheep exposes this capability to the masses by automating the process so that absolutely no technical know-how is required. Unfortunately, it is actually quite difficult to defend against Firesheep because most sites only permit SSL connections during the initial login, not while surfing other pages. As such, while your username and password are encrypted, your session ID is available to all other machines on the same network.

In a previous post, Mike showed how to detect the use of Firesheep on a local network by using Wireshark and Scapy. Well, today, we're releasing a new Firefox add-on which makes the detection of FireSheep available to everyone and we're calling it BlackSheep!

BlackSheep installed

BlackSheep is a Firefox add-on which warns users if someone is using Firesheep on their network. It also indicates the IP address of the machine that is spying on you.

BlackSheep warns that someone is using FireSheep

Install BlackSheep add-on for Firefox 3.x

How BlackSheep works

To understand how BlackSheep works, we first need to understand the details of FireSheep. FireSheep listens to the HTTP traffic on port 80. When it identifies a transaction to a known site (Facebook, Google, Yahoo!, etc.), it looks for specific cookie values which are then used to identify a specific user. This phase of the attack cannot be detected as it is done passively.

When FireSheep identifies a user session, it then makes a request to the same site using the user's cookie values in order to retrieve user information such as their name, picture, etc. This active network activity is however visible to others on the local network.

BlackSheep detects the active connection made by Firesheep. It does this by making HTTP requests to random sites handled by FireSheep every 5 minutes (configurable) with fake values. BlackSheep then listens to all HTTP requests on the network to detect if somebody else is using the same fake values.

Use Firesheep to combat.... Firesheep!

BlackSheep is based on the FireSheep source code. It reuses the same network listening back-end and the list of sites and corresponding cookies, etc. This ensures that the fake traffic generated by BlackSheep is what Firesheep is expecting.

BlackSheep in action

First, install BlackSheep here. If you already have FireSheep installed, make sure it is disabled, otherwise BlackSheep will detect that you are using FireSheep.

Then select the correct network interface in the options menu (same as FireSheep).

BlackSheep preferences menu

By default, BlackSheep generates fake traffic every 5 minutes. You can change this value in the option settings.

If Firesheep is detected, you will see the following warning in your current browser tab.

BlackSheep notification

Finally, here is a video of BlackSheep in action.

Install BlackSheep add-on for Firefox 3.x

Surf safe!


In order to install BlackSheep, you need:
  • Mac OS X: 10.5 or newer on an Intel processor.
  • Windows: XP or newer. Install Winpcap first!
  • Linux:  available here
  • Firefox: 3.5 or newer. 32-bit only.

-- Julien

Friday, November 5, 2010

Recent trends in Blackhat spam SEO

Blackhat spam SEO is still very present on the web, and there have been more changes in the past few weeks than in the months before. Here are some of the evolutions that began in the past few weeks.

More diverse TLDs

A few months ago, most of the malicious fake AV pages were hosted on .co.cc sub-domains. When the hosting providers started to shutdown these sites, the attackers pretty much deserted the TLD. The malicious pages are now spread amongst various TLDs: .NET (securityptenea.net, true-protection35.net, etc.), .IN (saveaybeve.in, lastyourholder.in, smart-filechecker.in, etc.), back in .co.cc (photolocations.co.cc, zyvsmywn.co.cc, etc.),  .cz.cc (4mut.cz.cc, 4fsb.cz.cc, etc.), IP addresses (,, etc.), etc.

These sites seem to be shutdown at a steady pace, but new ones re-appear just as quickly. .IN domains are the most common in recent days.

HTML encoding

After starting to insert random white space in HTML code, fake AV pages now use HTML entities to encode HTML in random places. These simple techniques can defeat basic string-based signature detection.

HTML encoding (Securty Analysis) and white spaces in the source code
JavaScript obfuscation

It used to be quite rare to find obfuscated JavaScript in fake AV pages. Not anymore. But surprisingly, the attackers have chosen not to encode the CSS included in the same file, which makes it very easy to detect these pages.

Obfuscated JavaScript

JavaScript redirections

Another technique now widely used to evade security tools is to include an additional HTTP redirection by using one JavaScript statement: document.location=NEW_URL, window.location=NEW_URL or location.assign(NEW_URL).

JavaScript redirection toe actual malicious page on the same domain.
This redirection is done on the malicious domain, not on the spam page.

More actors

This is something I mentioned in previous blog posts. There are more and more newcomers who are using Blackhat spam SEO to make a few bucks: fake search engines, download sites, video sites, etc. These sites do not spread malware, but they use hijacked sites to add spam pages.

Spam page for a movie site on the hijacked domain crcomunicaciones.com

Since there are more groups in the spam SEO game, the spam pages look different (different content and different URLs), and the overall number of spam pages in popular searches remains high despite Google's effort to tackle this issue. I should however point out that the number of spam pages leading to malicious content has gone down since the beginning of the year.

-- Julien