Botnets for everybody!

BBC's Click technology program decided to demonstrate the SPAM power of botnets by directing 22,000 zombies in their own personal botnet. Sure, a lot of people are questioning the legality of this stunt, but that's not what really caught my attention. Most live hacking demonstrations involving real targets are legally questionable anyways, and despite the laws many people feel entitled (and sometimes even obligated) to do XSS and SQLi testing against arbitrary web applications on the Internet.

What caught my eye was a few interesting choice remarks made in the article. First, they called their 22,000 node botnet "low-value." What, pray tell, makes this botnet particularly low value? Is it what hackers would charge to rent/sell it? Is it the number of nodes (a mere 22,000)? I think this is a great illustration of the inflated grandness that media has really driven to botnet stories...apparently botnets under a quarter-million nodes are worth less consideration. Yet by the article's own admission, it only took a scant 60 nodes to DDoS their target website off the Internet. Make no mistake, 22,000 nodes at an attacker's command can do a considerable amount of damage to just about any target. There are even supercomputers listed on the world's top 500 supercomputers list that leverage far fewer than 22,000 nodes. I would hardly trivialize a 22k node botnet with the label "low-value," as it desensitizes everyone to the overall threat that any sized botnet can represent.

Second, the article mentions they "acquired" their own botnet "after visiting some chatrooms" on the Internet. I wish they had provided a bit more details here...did they troll chat rooms until they found a botnet for sale, and purchase it? Or did they intercept an IRC-based command and control channel of the bots, thus hijacking the botnet to do their bidding? Either way, their candor regarding the ease of acquiring a botnet seems strange. I would think the story of how anyone can "visit some chatrooms" and walk away with a botnet would be more sensational than filling some demo inboxes with spam.

As an aside, the "how a botnet works" graphic they include in the article was a bit weird as well; the truncated version you see in the article leaves a lot to be desired ("Hacker -> virus"?). You have to click on the image to get the full chart, and then things become clear.

Until next time,
- Jeff

Vulnerable by design...no, really

Part of my responsibilities at Zscaler is to look through our log files in order to spot strange and unusual requests (new malware, botnets, etc.), questionable surfing trends, and other sorts of data-mining security goodness. And unfortunately, I routinely come across requests such as these:
Guilty.party.unnamed.com/static/sc_trans2_blue_li-350x250-1l-eng-nul.swf?clickTag=JAVASCRIPT:DL_GotoSurvey();&clickTag2=JAVASCRIPT:DL_Close();
Guilty.party.unnamed.com/global/video/JSinclude_flash.asp?ct=&src=%3Cscript%20src%3D%27http%3A//ad.doubleclick.net/adj/xxxxxxxx/wnvideo%3Bpos%3Dpre%3Bsz%3D2x2%3Bxx%3Dxxx%3Brn%3D39%3Btile%3D15%3Bord%3D0123456789%3F%27%3E%3C/script%3E
Guilty.party.unnamed.com/topshowstory_topad.php?script=<script%20language='javascript'%20src='/js/bannerscriptmp3internal2.js'></script>
Guilty.party.unnamed.com/video/<script%20type="text/javascript"%20src="http://some.other.party.com/adsc/d495261/7/498588/randm.js"%20/>&rndNum=99812610
Guilty.party.unnamed.com/ifr.php?x=%3Cscript+type%3D%22text%2Fjavascript%22%3E%3C%21--%0Agoogle_ad_client+%3D+%22pub-9310xxxxxxxxxxxx%22%3B%0Agoogle_ad_width+%3D+468%3B%0Agoogle_ad_height+%3D+15%3B%0Agoogle_ad_format+%3D+%22468x15_0ads_al_s%22%3B%0A%2F%2F2007-10…
Anyone familiar with web security will likely see immediately that these requests essentially carry cross-site scripting payloads. But these are not an XSS attack against a user; I’ve traced all of these (and many, many more), and they are, in fact, required to happen that way by a legitimate web site. That’s right folks: there are sites passing Javascript in URL parameter fields on purpose. Most of the URLs I've discovered that have XSS by design typically fall into one of two types: advertising syndication, or passing HTML into a SWF. All of the above URLs exhibit one of those two types. The last listed URL probably gets the 'Hall of Shame' award, since the ifr.php was designed to return arbitrary content that is meant to be used in an Iframe.
But XSS is just the tip of the iceberg; check out these requests:
Guilty.party.unnamed.com/globalpages/search-results.asp?SQLStmt=SELECT+KEY%5F%2C+AD%5FNO%2C+AD%5FNAME%2C+TYPE%2C+SPECIAL1%2C+SPECIAL2%2C+SPECIAL3%2C+SMALL%5FIMAGE%2C+personalizable+FROM+graphics+WHERE+%28%28type+%3D+%27PhotoFile%27%29+AND+%28color+%3D+%27Color%27%29+AND+%28keywords+LIKE+%27%25wedding%25%27%29%29+order+by+date%5Fadded+desc&showpage=3&…
Guilty.party.unnamed.com/common/sessionshare.aspx?context=flash&debugSQL=SELECT+top+20+%2A%2C+round%283959+%2A+acos%28++++++sin%2842%2E944498%2F57%2E3%29+%2A+sin%28%28google%5FLatitude+%2B+0%2E0001%29%2F57%2E3%29+%2B+++++++cos%2842%2E944498%2F57%2E3%29+%2A+cos%28%28google%5FLatitude+%2B+0%2E0001%29%2F57%2E3%29+%2A+++++++cos%28%28google%5FLongitude+%2B+0%2E0001%29%2F57%2E3+%2D+%28%2D85%2E617924%29%2F57%2E3%29%29%2C+2%29+as+Di
Are those full and partial SQL queries/clauses in the URL parameter fields? Why, yes they are! These sites actually pass the SQL query strings in as request parameters. Now, perhaps these sites have absolutely perfect database security, the web scripts use a read-only account DB account, and SQL access is restricted to a limited view of the table...meaning the web script isn't exploitable to do much beyond just read the already-public read-only data from a single table. But my bet is that isn't the case.
There are lots of other pretty scary requests out there, but it's hard to tell whether they are really exploitable or not by just looking at the URL (and I'm not about to go and perform an unauthorized security assessment on these public web sites). Here are some of the suspicious ones, for your entertainment:
Guilty.party.unnamed.com/XXXXXXLight.asp?request=%20shopping&Engine=http%3A%2F%2Fguilty.party.unnamed.com%2F&PartnerId=138&CssStylesLocal=c%3A%5Cinetpub%5Cwwwroot%2Flight%2Fskins%2Fembed_it_1_1.css&…
Guilty.party.unnamed.com/includes/include_once.php?include_file=http://some.other.party.com/sugar/1.gif?/
Guilty.party.unnamed.com/campaigns/showban.php?CD=B&M=1&D=&cb=<?php%20print%20(rand());?>
I'm sure I'll be posting more in the weeks to come. There doesn't appear to be a shortage of new examples...
Until next time,
- Jeff

Interim Patches

On September 16, 1997, Apple named Steve Jobs Interim CEO, a year after returning to the company that he had founded. Bud Selig served as interim commissioner for six years before Major League Baseball officially handed over the reins in 1998. When businesses face big challenges and a perfect solution isn't imminent, they implement an interim solution. It may be temporary, it may be imperfect, but something is better than nothing. Why then is the software industry so opposed to interim patches?

Two weeks ago, Adobe acknowledged a vulnerability in most versions of Adobe Reader that could lead to remote code execution. In that same advisory, they announced that a patch would be issued by March 11, leaving arguably the majority of computers exposed to attack worldwide. To make matters worse, security firms have suggested seeing attacks as early as the beginning of 2009 leveraging this attack vector. One would therefore presume that Adobe has had knowledge of this issue for some time.

Adobe went on to suggest that users disable JavaScript in order to protect themselves. That advice was short lived as on March 3rd, Dave Aitel announced that Immunity had released a working exploit which did not require the use of JavaScript. Not to worry though, as Adobe also assured customers that it was working with anti-virus vendors to ensure that signature based detection would be available to protect against potential attacks. How's that working out? A quick check with VirusTotal shows that as of this evening, only 5 of 39 AV vendors have protection in place for the proof of concept exploit released on February 22nd. That's less than 13% of vendors for an exploit for which source code has been available for nearly two weeks! It's tough to argue with Damballa's recent bashing of the AV industry.

The security industry on the other hand had a very different reaction. Lurene Grenier of SourceFire, released a homebrew patch just three days after the Adobe Advisory. Now I find it hard to believe that if a sole researcher, with no access to source code or exclusive knowledge of a given product can implement basic protection within days, that Adobe cannot do the same, with better quality, in a short time frame. I'm not asking for a perfect solution - I can wait until March 11 for that. I'm asking for an interim patch - a quick fix to a big problem. Yes, I'm willing to accept the risk that it will break something and hinder my ability to view PDF documents. Heck, I'm even willing to accept that it will erase a few. I'm willing to accept that risk, because it is far less damaging than the prospect of unwittingly joining the next botnet army. Sadly, while the recent Adobe debacle has become a poster child for the availability of interim patches it's only the latest high profile vulnerability representing a problem that won't go away on it's own.

Our industry loves to fuss and debate over formulas and approaches to determine risk. Rather than kick off a study group to study the work of another group, let me cut to the chase and propose a simple questionnaire for the entire software industry. The next time an evil-doer exposes a vulnerability in one of your software products, ask yourself three simple questions:

- Are more than 10% of Internet users affected?
- Is an exploit in the wild?
- Will it take more than 7 days to release a permanent fix?

If you answered yes to all of the above questions - stop reading and start writing - a quick and dirty patch that we can all use to protect ourselves.

- michael

The Horror Browser

I was thinking about security usability (as usual) when I stumbled across Nayan Ramachandran's article about what makes a horror game scary. Hmm, some of these scare tactics sound familiar. For your entertainment if not edification, I present the horror browser.

On your first visit to a site you have never visited before, the browser darkens and plays the sound of a door creaking slowly open.

Suddenly, a zombie jumps out of the window to inform you that there is a problem with the site's SSL certificate. You are jaded, so you click through, finding the popup more and more irritating and less scary each time you see it.

Sometimes, when you submit a non-SSL form, an animated gremlin runs off the screen with your data.

Whenever you send cookies, you can hear your browser breathing, and the occasional choked sob indicates it encountered a web bug.

The browser makes periodic eerie noises whenever one of its plugins is vulnerable. Will your machine be infected?

Whenever you encounter an HTTP redirect to an explicit IP address, the browser shows sinister-looking spinning things in an attempt to distract and confuse you.

It's been weeks, and you and your vulnerable plugin are doing just fine, when you hear the eerie noises again, only this time, you see the flicker of a monster running across the browser window. As the monster closes the mini-blinds over the page you were viewing, you realize your home page has been hijacked.

You get email from your bank. Your webmail application shows a harmless looking child who says your account will be cancelled if you don't re-enter your personal information. Just as you enter your social security number, you realize: it's not your bank at all. Too late!

On the one hand, this is pretty silly, both for itself and because most of the Web is not out to get you. On the other hand, users make security decisions based on how secure they feel, not how secure the situation actually is. So, tying the language of fear to risky online security decisions (provided the browser actually knows which decisions are risky) could help users make better decisions in these cases. As Matthew Gallant comments,

Enemy aesthetics should repulse the player before the actual "threat" can be evaluated; ideally the player should feel a sense of "I don't want that thing near me" before it gets close to enough to prove harmful.

Sleep well, don't let the zombies get you, and send me some screenshots if you see the gremlins.

--Brenda

Demystifying/Abusing Flash Cookies

Flash Cookies (aka Local SharedObjects) are increasingly being leveraged by developers as a powerful alternative to HTTP cookies, yet there seems to be significant confusion as to what they are capable of and what security/privacy risks they may expose. I feel that most users are at least familiar with cookies in general, and to some extent this technology has taken a bad rap as a privacy concern. While cookies certainly can lead to privacy concerns, we should keep in mind that they have become a key component in today's rich web applications, enabling persistence which is leveraged for authentication, user preferences, etc. As end users have become increasingly uncomfortable of the existence of data which permits sites to track their web clicks, they have begun disabling cookies within their browsers or adopting applications which permit the blocking of cookies. Yet, what many don't realize, is that the same tracking features they are trying to avoid are not only alive and well, but exist in a much more powerful form, thanks to Flash cookies.

Local SharedObjects were first introduced in Flash Player 6.0 in March 2002, so they've been around for a while. Combine this with the fact that (thanks largely to YouTube) Adobe is able to claim being present on 99% of Internet enabled desktops and Flash becomes a de-facto standard client side platform. Flash Cookies offer developers more flexibility than their HTTP based counterparts in virtually every category:

• Storage Capacity - By default, sites can store up to 100K of data on a local file system and no explicit consent is required form the end user. HTTP cookies can likewise store data without asking permission but are limited to 4K in most browser implementations.
• Expiry - HTTP cookies are either session based, meaning that they are wiped upon exiting the application/browser or have an explicit expiration date. Flash cookies on the other hand, by default have no expiration.
• File Format - Flash cookies are stored in a binary format, but contain text based data, so they're easy to read directly from the file system, so long as you know where they're stored (see below). There are also a variety of LSO readers that can be used.

LSO Storage Locations

• Windows XP
• $user\Application Data\Macromedia\Flash Player\#SharedObjects
• Windows Vista
• $user\AppData\Roaming\Macromedia\Flash Player\#SharedObjects
• Mac OS X
• ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects
• Linux
  
  • /home/$user/.macromedia/Flash_Player/#SharedObjects

From a developers perspective, the greatest advantage of Flash cookies appears to be the fact that users aren't overly familiar with them an wouldn't know how to delete them even if they were. In fact it wasn't until Flash Player 8.0 was released that Adobe actually added a Settings Manager to permit users to see and manage the Flash cookies on their system. This is the same control panel which was previously vulnerable to clickjacking. Browser privacy features which permit users to wipe local content including HTTP cookies do not presently touch Flash cookies, although I wouldn't be surprised to see this change over time.

Common security concerns for HTTP cookies outside of privacy involve cookie hijacking or injection or more generically, the ability to read from or write to a user's cookies. This is a significant threat given that cookies maintain persistence for authentication purposes and it is especially concerning given the prevalence of cross-site scripting vulnerabilities which facilitate such attacks.

Is cookie hijacking/injection possible with Flash cookies as can be done with HTTP cookies? The answer is yes, so long as the attacker has an ability to upload Flash content to the target domain. While this is a significant hurdle, the prevalence of Flash on the web and the acceptance of user supplied content on web sites, means that this isn't as difficult a challenge as you might think. As with HTTP cookies, Flash cookies enforce a same origin policy. Flash cookies can also restrict access based on the path where the Flash cookies are deployed. For example, a site where users have personal content (e.g. domain.com/user_page/), which stored all file uploads in one place (e.g. domain.com/all_files/) instead or user specific locations (e.g. domain.com/user_page/all_files/) could expose itself to attack. If Flash content can be uploaded, an attacker simply needs to build a Flash file which can read from/write to an existing LSO. While the name of the LSO is required, this is a trivial challenge as such data is already stored on the client side. The following ActionScript code sample permits writing to a Flash cookie:

package {

import flash.net.SharedObject;
import flash.display.Sprite;

public class zscaler extends Sprite {
private var user:SharedObject;
private var firstname :String;
private var lastname:String;
public function zscaler() {

user = SharedObject.getLocal("zscaler");
firstname = "Michael”;
lastname = "Sutton";

user.data.firstname = firstname;
user.data.lastname = lastname;

user.flush();
}
}
}

Once the code is written, it must be compiled into a *.swf file, which can be done using freely available tools such as the Adobe Flex 3 SDK, which includes a Flash compiler. In the above example, an LSO named zscaler is created which has two variables (firstname and lastname). Reading from an existing Flash cookie is equally as easy:

…
public function zscaler() {
var label:TextField;

user = SharedObject.getLocal("zscaler");

firstname = user.data.firstname;
lastname = user.data.lastname;

label = new TextField();
label.autoSize = TextFieldAutoSize.LEFT;
label.background = true;
label.border = true;
label.text = "Firstname: " + firstname + "\nLastname: " + lastname;

addChild(label);

user.flush();
}
…

The code has been abbreviated as it's largely identical to the previous sample. In this case, we once again call getLocal() using the name of an existing LSO and then simply read existing data (e.g. user.data.firstname). The example will display the contents of these variables in a text box.

If you're curious to know how many sites are leveraging Flash cookies, simply check the Website Storage Settings panel in your Adobe Flash Player Settings Manager. I suspect you'll be surprised to see how many sites are leveraging this technology. Also take time to browse through the content of these LSOs. Given the larger storage capacities available, you may find some interesting and perhaps insecure content.

Take care.

- michael

Big, white, puffy clouds can still evaporate

If you haven't heard by now, Google GMail had a 2.5 hour outage on Tuesday. Acacio Cruz, Gmail’s Site Reliability Manager, explained in a little more detail regarding the outage. My interpretation of his explanation is that they had a bug in how data is shifted around in the cloud, and during a shift one of data centers couldn't handle the new burden, failed, and eventually the effect cascaded.

I have a few comments on this. First, GMail still carries the 'beta' moniker...and aren't service disruptions like this kind of expected/tolerated with beta software? But beta or not, real people use the service--including Google themselves (according to Acacio Cruz's post). So maybe it's time to promote GMail out of beta and designate it as production, since that's what it is to most people anyways.

Second, running a resilient cloud is hard, particularly when it comes to outages and the resulting automatic rebalancing to cover the gap and maintain availability. It's like a tire on a car: everything rotates routinely and drives smoothly when the tire is balanced. But if the center of balance of the tire shifts dramatically at a random moment, things quickly deteriorate and the high-speed rotation can cause significant instability and damage to the rest of the vehicle. Computing clouds are conceptually similar. What happens when an outage takes out a piece of the cloud and the finely orchestrated balance is randomly skewed...is the capacity of the rest of the cloud sufficient to absorb the load? Can the cloud rebalance itself gracefully? These are the same types of questions one will hear when investigating fault tolerance, failover, and redundancy capabilities of any normal technology component (servers, firewalls, WAN links, etc.). But the questions take on a whole new level of scale when you apply them to a cloud.

Plus let's not overlook the fact that we have different fault tolerance expectations for services in the cloud. The typical perception of clouds seems to imply internal failover capabilities. After all, that's part of the appeal of clouds: all that fault tolerance, redundancy, etc. is magically taken care of within the cloud. The cloud is infallible. The cloud cannot fail. Those are the dominant marketing messages. No one talks about having a contingency plan for when the cloud is unavailable (what would that be exactly? A second hot-spare cloud?).

So when choosing a cloud-based vendor, you should try to investigate their cloud resiliency. Vendors who take non-cloud specific software, run copies of it in two or three datacenters, and call it a cloud service are likely not delivering the true expected experience to customers. Software needs to be purpose-built to run in a cloud, including multi-tenancy design and strong internal failover capability. That's because most people wind up putting all of their eggs into the cloud basket. If you are going to be one of those people, you should try to make sure the basket offers the implied safety that you expect.

Until next time,
- Jeff

EV-SSL, SSL, and who’s not using it

It seems I've been picking on EV-SSL lately. It's not intentional; I just have encountered a lot of questionable marketing fluff lately and wanted to talk about it. Today is no different. Tim Callan's recent blog post got me thinking. Basically he referenced some SSL attacks that were disclosed at BlackHat, and suggested EV-SSL certificates as the cure to SSL MitM attacks and phishing in general. On the one hand, I believe his conclusion is conveniently aligned with his employer's sales agenda. On the other hand, I acknowledge that EV-SSL could raise the bar...if it's adopted and deployed in widespread fashion. And therein is the crux.

I've previously talked about the EV-SSL adoption rate (or lack thereof) in this blog. NetCraft has reported its findings of one million valid SSL-capable sites are in use (note: sites with invalid, self-signed, or expired SSL certs are not included in that count). And while I don't have access to their commercial SSL Survey report for January 2009, we infer from some third party mentions that the report states around 10,000 EV-SSL sites were found. That's 3,000 more than Verisign mentioned last month, but perhaps Verisign was only reporting what they alone issued. Given their marketshare (~75%, albeit that number is a year old) against total EV-SSL cert vendors, that seems to make sense.

Only 10,000 EV-SSL sites within two years seems very low to me, especially for something which is essentially an enhanced derivative of an already understood and accepted technology. People already know what SSL is and what function SSL certs perform, so that definitely is not the hold up. There just doesn't seem to be much of an adoption momentum, and maybe that's because the additional value these premium EV-SSL certs provide is questionable in the eyes of site owners.

But maybe I'm looking at this wrong. Only 10,000 EV-SSL sites seems a bit low, but what if they were 10,000 sites that matter? I suppose that would paint a different picture. If 10,000 big sites that account for a notable portion of the web's traffic used EV-SSL, I suppose that actually might not be so bad. So I entertained that theory. I manually surfed to each of the upper 50 of Alexa's Global Top 500 Sites list, and recorded who was using EV-SSL vs. normal SSL vs. no SSL. The idea is that these sites represent the most visited sites in all of the world (according to Alexa), and as such, assumingly have a vested interest in assuring their voluminous user population that the users' accounts and transactions are secure. If most of these sites were using EV-SSL, then that would actually provide notable EV-SSL permeation into overall web traffic.

The process I used was simple: visit each of the Alexa-listed sites (the top 50), surf around to find a 'signin' or 'signup' form or other equally-sensitive use of HTTPS, and then watch if the URL address bar in my Internet Explorer 7 browser turned green when SSL was utilized. A green bar meant EV-SSL; no green bar but still having a valid lock icon is standard SSL. I found that only two sites (ebay.com and login.live.com) were using EV-SSL. That's it. Just two. All of the other sites were using standard SSL, with the exception of ten sites that don't use SSL at all with their login forms (youtube.com, hi5.com, mail.ru, photobucket.com, vkontakte.ru, imageshack.us, friendster.com, skyrock.com, odnoklassniki.ru, and dailymotion.com) and two more that don't really receive sensitive info from the user and thus don't necessitate SSL (bbc.co.uk and cnn.com).

We might label that a bleak picture. Ten of the fifty top sites (20%) don't even use SSL for their logins. Only two use EV-SSL. I was a bit surprised to see the online retail giant, Amazon.com, didn't use EV-SSL. If EV-SSL was a sure-thing to lead to better customer confidence and more online retail conversions, I would have figured they would have been all over it. They would not be one to overlook a technological advantage if the ROI helped their bottom line...that is, after all, how they got started. And given that they store credit card data for quick purchasing convenience, there is a certain financial value to compromising someone's Amazon account; I’m surprised it hasn't been the target of more phishing attacks to date.

Also surprising was Yahoo (login.yahoo.com), AOL (my.screenname.aol.com), and Google (www.google.com) all use standard SSL for their common backend authentication sites. These vendors offer multiple different web services, but tie it all back to a single authentication mechanism, much like a Single Sign-On (SSO) platform. And aren't some of these vendors OpenID providers? That means a successful phish of a single account could be leveraged across many sites/services, even outside the realm of just these vendors. On Microsoft's live.com site, I found that the login form (from login.live.com, which was presented over HTTP by default but did include a link to switch to HTTPS) did go to an EV-SSL site once submitted, but the signup page (signup.live.com) was handled with a standard SSL cert. Maybe they just want to discourage new signups while assuring existing accounts it's safe to login.

But here's another thought: maybe these sites have invested in standard SSL certificates before EV-SSL was popular, and just are waiting for their current certs to expire before renewing with EV-SSL variants. That seems plausible, but the results are a bit mixed. Google renewed their current standard SSL cert in May 2008 and signup.live.com was renewed in November 2008. That was fairly recent, and definitely after EV-SSL was well established. Opposite that, AOL's my.screenname.aol.com certificate was issued in March 2007 and Yahoo's is from January 2006; it's arguable they were issued before EV-SSL really caught on. So it's hard to say, but the thought might hold true for some cases. Certainly not others.

But again, maybe I'm still looking at it all wrong. EV-SSL might only make the most sense to certain verticals, like online banking sites. The Alexa list doesn't really have any bank sites in their top 50. So I did a spot-check of some big bank site URLs pulled from the top of my head. Of all the ones I tried, only BankOfAmerica's login site (which is separate from their normal site) used EV-SSL:

• www.bankofamerica.com: standard SSL (renewed December 2008)
• sitekey.bankofamerica.com: EV-SSL
• www.wellsfargo.com: standard SSL (renewed June 2008)
• online.wellsfargo.com: standard SSL (renewed July 2008)
• www.chase.com: standard SSL (renewed August 2008)
• chaseonline.chase.com: standard SSL (renewed April 2008)
• online.citibank.com: standard SSL (renewed December 2007)
• www.us.hsbc.com: standard SSL (renewed July 2008)
• myonlineaccounts2.abbeynational.co.uk: standard SSL (renewed February 2009**)

That last one is very interesting. Abbey National Bank has been a notable target of phishing attempts going back a year. And yet, when they renewed their SSL certificate last week (February 12, 2009), they went with a standard certificate instead of EV-SSL. Whether they didn't know or didn't care that EV-SSL could help assure users against phishing, I don't know. But if a bank that's been phished for over a year doesn't decide to buy into EV-SSL when it has the convenient opportunity...who will? Marketing fluff aside, that is probably the absolute best-case realized application for EV-SSL ever. User accounts have access to monetary instruments. The site has been an active target of phishing attempts for over a year. They needed new SSL certs anyway. Any one of those reasons by itself is (supposed) ground for EV-SSL, and they had all three reasons. Oh well, maybe they're reconsider EV-SSL in 2010 when their new cert expires.

Until then,
- Jeff

**Postscript: it seems Abbey National Bank's site uses a cluster of SSL web servers that have different SSL certs installed. In some cases, I connect to a server that gives me an SSL cert that was issued on Feb 12 2009. On other occasions, I get connected to a server that gives me an SSL cert that expires on Feb 24 2009 (i.e. next week). So apparently they have currently upgraded the SSL certs on some of their servers, but not all. I just wanted to mention this in case you were poking around yourself and noticed the discrepancy. Here is a screenshot of the newer SSL cert, to prove I'm not making stuff up: