Spyware Sucks

Well, I said I would get in touch with Doubleclick - their response was interesting - I quote:

"it's to confuse people... look you get the same results:

openadstream.net/ad0.php?url=http://www.google.com/click/nxtgcbb80290000125ave/direct/wi/ai&key=V24567233828272323&c=127500043

openadstream.net/ad0.php?url=http://www.microsoft.com/click/nxtgcbb80290000125ave/direct/wi/ai&key=V24567233828272323&c=127500043"

The original URL I provided was:

openadstream.net/ad0.php?url=http://ad.doubleclick.net/click/nxtgcbb80290000125ave/direct/wi/ai&key=V24567233828272323&c=127500043

Each of those URL renders the same result - a plain white white page with the text "stats=917174773"

Oh, and guess who supplies the name servers for openadstream.net - yep, you guessed it - estboxes.com aka estdomains - a domain that has already been mentioned once in my blog today.

I received this email today via my Spyware Sucks "Contact Me" link:

"At least a have a problem that i find no pleasent, i think it comes from your url, a receyve continusely messages that my pc is infected by viruses or spam.  I ask you for  all of your possibilitys no more sending those messages in the future on my pc. What kan i do for removing this messages always a receyving ?  Ps) a appologise for the grammatical faults in the mail becaaause my english is not my primary language."

Ok, so we all know that my blog does not harbour any advertisements that could trigger such an effect therefore I feel grave concern that his computer is already infected.

English is his second language so it is going to be difficult to assist him.  His email address is an @pandora.be address, so if anybody knows what his native language is, feel free to comment...

Oxfam does fantastic work - in fact several people received "Oxfam Unwrapped" gift cards from me for Christmas (donations on their behalf) - and it makes me FURIOUS to see Oxfam's good name taken advantage of, and a malicious advertisement featuring their name used as a conduit to fraudware.

I received a sample SWF today, an advertisement touting Oxfam - screenshots below.

An examination of the internal code reveals:

www.errorsafe.com/pages/scanner/index.php?aid=50ftf0rm&lid=sw23&ax=1&ed=2, __self.str, _root.c4.color(14688422)

which redirects to:

errorsafe.com/download/2007/index.php

Y'know, I already do all I can to track down, and shut down, the bastards behind malicious banner advertisements.  I promise you this, if there is one thing that the criminals can do to make me even more determined to chase them to the ends of the earth, it is to do something like impersonating Oxfam.

Interesting. 

"openadstream.net/ad0.php?url=http://ad.doubleclick.net/click/nxtgcbb80290000125ave/direct/wi/ai&key=V24567233828272323&c=127500043"
"iexplorer-security.org/?id=463400043"

iexplorer-security.org has hidden some information behind Privacy Protect, but we can find out some things.

First, iexplorer-security.org is hosted by Masterhost in Russia.  Second, its nameservers are provided by the infamous eshosst.com (aka estdomains) - the list of malicious/fraudulent domains associated with Estdomains is staggering.

I'll need to get in touch with Doubleclick about their appearance in a variable.

More later... I'm out of office at the moment and don't have access to my normal toolset.

Screenshot:

Online analysis of SWF:
http://www.adopstools.net/index.asp?page=richmedia&quicklink=2526I2UFLC7Ri029&section=clickchecker&file=1-curves728x90.swf 

Just like Skyauction, Emusic and QPAD before them, Firstchoice have advised that they have nothing to do with the malicious advertisements featuring their company.

I quote the contents of an email from Firstchoice to the web site that supplied the copy of the malicious advertisement from Forceup to me for analysis:

"1. Our site [is] firstchoice.co.uk not firstchoice.com. (Which is a chain of hairdressers in the US!)

The SWF has been analysed.  We find this URL in the code:
quinquecahue.com/statsa.php?u=1202136191&campaign=oseximious 

The allowed countries for this particular malicious campaign are ZA, US and UK

Banned IPs: 

209.160.0.0-209.160.255.255 Hop One Internet Corporation
196.36.0.0-196.36.255.255 (Internet Solutions (Pty) Ltd (South Africa)

Banned cities: Johannesburg, Tukwila

Kudos to Kimberley for decrypting the SWF contents.

I received an email tonight warning me that a Diane Samuels from forceup.com is contacting web sites wanting to place an advertising banner.  I was contacted by those behind a web site with checks in place that identified the advertising banner as "a virus of some sort".

The creative's name was firstchoise_728x90.swf.

"Diane Samuels" did not respond to emails from the web site's staff once they discovered that the advertisement was bad - a failure to respond is standard operating procedure for the b*stards behind the malicious advertisements - if they get caught by one web site, they just move on to the next one.

Forceup.com is a well known name to those of us who watch and report on malicious banner advertisements - if you search this blog for that name you will find that forceup is mentioned nine times.

First, I am *very* pleased that the intended victim site's checks and balances alerted them to a problem, aka "a virus of some sort".

Second, I am *very* pleased that the creative was detected as a virus.

Third, I have a copy of the actual creative that I can analyse it and report on, and provide screenshots.

An analysis of the creative at adopstools reveals that the creative contains "a sprite/movieclip which is containing Malware actionScript code".

Here are screenshots of the advertisement provided by forceup.com - you have been warned. 

If I receive further information I will blog again.

Those of you with a technical mindset may find this explanation about what happened, and the timeline, informative:
http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube.shtml

Some chatter at NANOG (with a few glimmers of paranoia to add spice):
http://www.merit.edu/mail.archives/nanog/threads.html#06347

Here you go - this month's new KB articles.  You know what they say.. never lose sight of your roots.. and for me, my roots are buried deep in supporting users of Internet Explorer from a technical perspective, not a spyware/malware perspective, and let's face it - when was the last time you saw a kernel32.dll error caused by a video driver? IE is *way* more stable than it used to be.

Maybe things will hot up on the Internet Explorer scene now that the IE8 beta is around the corner.  I confess to feeling some excitement when I think about putting IE8 through its paces.  The team have been very secretive - not even *I* know for sure what's coming.

Anyway, let's take a look at the new Knowledgebase articles for this month....

------

IE6 and IE7:  An Internet Explorer Automatic Component Activation (IE ACA) Preview #2 update is available to disable the "Click to activate" behavior

Microsoft is releasing an Internet Explorer Automatic Component Activation (IE ACA) update that will disable the “Click to activate” behavior of the Internet Explorer ActiveX update that was originally released in April 2006.

It is strongly recommended that this update only be deployed for testing purposes.

http://support.microsoft.com/default.aspx/kb/947518

-----

IE5.01, IE6, IE7:  MS08-010: Cumulative security update for Internet Explorer

Microsoft has released security bulletin MS08-010. The security bulletin contains all the relevant information about the security update. This information includes file manifest information and deployment options, as well as known issues.

http://support.microsoft.com/default.aspx/kb/944533

-----

IE6 and IE7:  You may be unable to view some PDF documents in Windows Internet Explorer 7 or in Internet Explorer 6

This problem occurs because of the method that is used to determine the MIME type of downloaded content. This problem occurs even if the content MIME type is declared as "application/pdf."

http://support.microsoft.com/default.aspx/kb/945686

-----

IE6:  If you configure Internet Explorer 6 to use a proxy autoconfiguration (.pac) script, URLs may be identified as being in the Internet zone instead of as being in the local intranet zone

This problem occurs because Internet Explorer (Iexplore.exe) starts to process the .pac script when it first connects to the network from the client computer.

If the security zone of the target URL is identified after the exception list of the .pac script is read, the Web site is displayed as being in the local intranet zone. Conversely, if the target URL is accessed before the exception list is read, the Web site is identified as being in the Internet zone.

Therefore, depending on the timing, the .pac script may incorrectly identify a URL as being in the Internet zone instead of as being in the local intranet zone.

http://support.microsoft.com/default.aspx/kb/946240

-----

IE6 and IE7: Internet Explorer uses HTTP/1.0 GET requests instead of HTTP/1.1 GET requests to connect to a Web site

This problem occurs because of a design change in how the Wininet.dll file reads the values of the Use HTTP 1.1 option and the Use HTTP 1.1 through proxy connections option as a policy. In this case, the Security_HKLM_Only registry entry is enabled. This design change does not consider the effect of the Security_HKLM_Only registry entry. When the Security_HKLM_Only registry entry is enabled, the default settings for the Use HTTP 1.1 option and for the Use HTTP 1.1 through proxy connections option are set to be disabled. By default, the EnableHttp1_1 registry entry and the ProxyHttp1.1 registry entry do not exist. Therefore, when the Wininet.dll file tries to read them in the registry, the values of these registry entries are determined to be turned off.

The Security_HKLM_Only registry entry is stored in the following registry subkey:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings

http://support.microsoft.com/default.aspx/kb/947513

-----

IE7: Windows Internet Explorer 7 may exit unexpectedly when you view a Web page that sets a scroll bar style attribute for an element

When you view an HTML page that uses scroll bar (scrollbar) style attributes for an element, Windows Internet Explorer 7 may exit unexpectedly. Additionally, you may receive an access violation error message in the Mshtml.dll file.

http://support.microsoft.com/default.aspx/kb/942368

-----

Error message when you run a script that is encoded by using Script Encoder (Screnc.exe) in Windows Server 2003 or in Windows XP

This problem occurs because the non-encoded scripts use comments as encoding markers. These comments resemble one of the following:

• '**Start Encode** for Microsoft Visual Basic Scripting Edition (VBScript) 
• //**Start Encode** for JScript 

These comments and the lines that come before them should be visible in the encoded script. However, they are invisible.

http://support.microsoft.com/default.aspx/kb/948527

Well, the EV problem experienced at Tim Callan's blog has been fixed - by removing Google Analytics and Feedburner tracking code from the page.  I should point out that Google's code was removed LAST, therefore it is possible that Feedburner may be blameless - we won't know for sure unless the site is tested with Feedburner tracking code reinstated.

This incident is a timely warning for web site owners to consider the security implications of all code that they add to their sites, especially their HTTPS sites.  If a site owner has invested the time and expense required to qualify for an EV certificate, they will not want their customer's experience to be complicated by error messages such as those we saw on Tim's blog. 

I note that Google Analytics code (when used on an HTTPS page) is not the only example of a Google service triggering the "This page contains both secure and nonsecure items. Do you want to display the nonsecure items?" error.  I have also seen the error on Gmail's log in page when the "Sign Up For Gmail" pane uses a graphic instead of a simple hyperlink.  Google also faced (faces?) a similar problem with their Google Checkout service which also triggered (triggers?) the error message - can you imagine how scary it would be for somebody purchasing products from a web site if they saw that error?

Cite: http://groups.google.com/group/google-checkout-api-troubleshooting/browse_thread/thread/5e855a0fee76b181/b0f83bbee904b8c4?lnk=st&q=%22This+page+contains+both+secure+and+nonsecure+items%22#b0f83bbee904b8c4

I also note that "someone at Google" had advised the complainant that the "available solutions" to get rid of the alert window are to use a different web browser or lower the browser security settings.

I'll be honest - as far as I'm concerned it is not acceptable in this day and age, from a security standpoint, to tell customers of any web site that they can avoid an alert message by "lower[ing] their browser security settings".  Just imagine if the site in question was hacked (or any site that the user visits which uses the same Internet security zone).  The negative implications for customers if they followed such advice is frightening.

Suggesting that people swap to a different web browser is taking the easy way out (as we know from Tim's experience changing web browser doesn't fix the green address bar problem anyway).

But, to be fair, his blog is not the only Verisign page that is missing the green address bar when it ought not...

Let's visit Tim's blog at https://blogs.verisign.com/ssl-blog/.  Check this out.

We load the URL - we see an alert about "secure and nonsecure items".  When we see this error it generally means that the page in question, an HTTPS page, includes content that is being pulled from an HTTP (no S) address:

If we click "Yes", we see this - no green bar:

If we click "No" we see this - a green bar:

I first blogged about this interesting phenomenon back in February 2007 - a year ago.  Methinks I need to get in direct touch with Tim and let him know about what I am seeing.  We've corresponded in the past, so I should have his address here somewhere....

BTW, Firefox Beta 3 introduces green address bar support for EV certificates without the need for an add-on:

Unless you are viewing a Verisign site, that is...

Interestingly, if you go to a different site, then use the back button to return to Verisign, the EV works...

Refresh the page, and the green bar will disappear.

As we know, EV certificates are not cheap, and it is important for Web site designers and site owners to bear in mind that if they are going to pay good money for, and go through all the rigmarole that must be endured to win an EV, then they must make sure that they are not going to inadvertantly break the green address bar.