Phishing still works, says Verisign:
...these latest messages masquerade as an official subpoena requiring the recipient to appear before a federal grand jury. The emails correctly address CEOs and other high-ranking executives by their full name and include their phone number and company name, according to Matt Richard, director of rapid response at iDefense, a division of VeriSign that helps protect financial institutions from fraud. ...About 2,000 executives took the bait on Monday, and an additional 70 have fallen for the latest scam, Richard said. Operating under the assumption that as many as 10 percent of recipients fell for the ruse, he estimated that 21,000 executives may have received the email. Only eight of the top 35 anti-virus products detected the malware on Monday, and on Wednesday, only 11 programs were flagging the new payload, which has been modified to further evade being caught.
I find 10% to be exceptionally large, but, OK, it's a number, and we collect numbers!
Disclosure for them: Verisign sells an an anti-phishing technology called secure browsing, or at least the certificates part of that. (Hence they and you are interested in phishing statistics.) Due to problems in the browser interface, they and other CAs now also sell a "green" version called Extended Validation. This -- encouragingly -- fixes some problems with the older status quo, because more info is visible for users to assess risks (a statement by the CA, more or less). Less encouragingly, EV may trade future security for current benefit, because it further cements the institutional structure of secure browsing, meaning that as attackers spin faster in their OODA loops, browsers will spin slower around the attackers.
Luckily, Johnath reports that further experiments are due in Firefox 3.1, so there is still some spinning going on:
Here’s my initial list of the 3 things I care most about, what have I missed?1. Key Continuity Management
Key continuity management is the name for an approach to SSL certificates that focuses more on “is this the same site I saw last time?” instead of “is this site presenting a cert from a trusted third party?” Those approaches don’t have to be mutually exclusive, and shouldn’t in our case, but supporting some version of this would let us deal more intelligently with crypto environments that don’t use CA-issued certificates.
Jonath's description sells it short, perhaps for political reasons. KCM is useful when the user knows more than the CA, which unfortunately is most of the time. This might mean that the old solution should be thrown out in favour of KCM, but the challenge lies in extracting the user's knowledge in an efficacious way. As the goal with modern software is to never bother the user then this is much more of a challenge than might be first thought. Hence, as he suggests, KCM and CA-certified browsing will probably live side by side for some time.
If there was a list of important security fixes for phishing, I'd say it should be this: UI fixes, KCM and TLS/SNI. Firefox is now covering all three of those bases. Curiously, Johnath goes on to say:
The first is for me to get a better understanding of user certificates. In North America (outside of the military, at least) client certificates are not a regular matter of course for most users, but in other parts of the world, they are becoming downright commonplace. As I understand it, Belgium and Denmark already issue certs to their citizenry for government interaction, and I think Britain is considering its options as well. We’ve fixed some bugs in that UI in Firefox 3, but I think it’s still a second-class UI in terms of the attention it has gotten, and making it awesome would probably help a lot of users in the countries that use them. If you have experience and feedback here, I would welcome it.
Certainly it is worthy of attention (although I'm surprised about the European situation) because they strictly dominate over username-passwords in such utterly scientific, fair and unbiased tests like the menace of the chocolate bar. More clearly, if you are worried about eavesdropping defeating your otherwise naked and vulnerable transactions, client-side private keys are the start of the way forward to proper financial cryptography.
I've found x.509 client certificates easier to use than expected, but they are terribly hard to install into the browser. There are two real easy fixes for this: 1. allow the browser to generate a self-signed cert as a default, so we get more widespread use, and 2. create some sort of CA <--> browser protocol so that this interchange can happen with a button push. (Possible 3., I suspect there may be some issues with SSL and client certs, but I keep getting that part wrong so I'll be vague this time!)
Which leaves us inevitably and scarily to our other big concern: Browser hardening against MITB. (How that is done is ... er ... beyond scope of a blog post.) What news there?
On the ease of getting client certificates into the browser, note that the NSS team has done some work on this in the past. Bob Lord at Red Hat probably can provide more information as to the sorts of things they were looking at.
Posted by: Frank Hecker at April 18, 2008 11:53 AM