Financial Cryptography

wheretofore Vista? Microsoft moves to deal with the end of the Windows franchise

Since the famous Bill Gates Memo, around the same time as phishing and related frauds went institutional, Microsoft has switched around to deal with the devil within: security. In so doing, it has done what others should have done, and done it well. However, there was always going to be a problem with turning the super-tanker called Windows into a battleship.

I predicted a while back that (a) Vista would probably fail to make a difference, and (b) the next step was to start thinking of a new operating system. This wasn't the normal pique, but the cold-hearted analysis of the size of the task. If you work for 20 years making your OS easy but insecure, you don't have much chance of fixing that, even with the resources of Microsoft.

The Economist brings an update on both points. Firstly, on Vista's record after 18 months in the market:

To date, some 140m copies of Vista have been shipped compared with the 750m or more copies of XP in daily use. But the bulk of the Vista sales have been OEM copies that came pre-installed on computers when they were bought. Anyone wanting a PC without Vista had to order it specially.

Meanwhile, few corporate customers have bought upgrade licences they would need to convert their existing PCs to Vista. Overwhelmingly, Windows users have stuck with XP.

Even Microsoft now seems to accept that Vista is never going to be a blockbuster like XP, and is hurrying out a slimmed-down tweak of Vista known internally as Windows 7. This Vista lite is now expected late next year instead of 2010 or 2011.

It's not as though Vista is a dud. Compared with XP, its kernel—the core component that handles all the communication between the memory, processor and input and output devices—is far better protected from malware and misuse. And, in principle, Vista has better tools for networking. All told, its design is a definite improvement—albeit an incremental one—over XP.

Microsoft tried and failed to turn it around, security+market-wise. We might now be looking at the end of the franchise known as Windows. To be clear, while we are past the peak, any ending is a long way off in the distant future.

Classical strategy thinking says that there are two possible paths here: invest in a new franchise, or go "cash-cow". The latter means that you squeeze the revenues from the old franchise as long as possible, and delay the termination of the franchise as long as possible. The longer you delay the end, the more revenues you get. The reason for doing this is simple: there is no investment strategy that makes money, so you should return the money to the shareholders. There is a simple example here: the music majors are decidedly in cash-cow, today, because they have no better strategy than delaying their death by a thousand file-shares.

Certainly, with Bill Gates easing out, it would be possible to go cash-cow, but of course, we on the outside can only cast our augeries and wonder at the signs. The Economist suggests that they may have taken the investment route:

Judging from recent rumours, that's what it is preparing to do. Even though it won't be in Windows 7, Microsoft is happy to talk about “MinWin”—a slimmed down version of the Windows core. It’s even willing to discus its “Singularity” project—a microkernel-based operating system written strictly for research purposes. But ask about a project code-named “Midori” and everyone clams up.

By all accounts, Midori (Japanese for “green” and, by inference, “go”) capitalises on research done for Singularity. The interesting thing about this hush-hush operating system is that it’s not a research project in the normal sense. It's been moved out of the lab and into incubation, and is being managed by some of the most experienced software gurus in the company.

With only 18 months before Vista is to be replaced, there's no way Midori—which promises nothing less than a total rethink of the whole Windows metaphor—could be ready in time to take its place. But four or five years down the road, Microsoft might just confound its critics and pleasantly surprise the rest of us.

Comment? Even though I predicted Microsoft would go for a new OS, I think this is a tall order. There are two installed bases in the world today, being Unix and Windows. It's been that way for a long time, and efforts to change those two bases have generally failed. Even Apple gave up and went Unix. (The same economics works against the repeated attempts to upgrade the CPU instruction set.)

The flip-side of this is that the two bases are incredibly old and out-of-date. Unix's security model is "ok" but decidedly pre-PC, much of what it does is simply irrelevant to the modern world. For example, all the user-to-user protection is pointless on a one-user-one-PC environment, and the major protection barrier has accidentally become a hack known as TCP/IP, legendary for its inelegant grafting onto Unix. Windows has its own issues.

So we know two things: a redesign is decades over-due. And it won't budge the incumbents; both are likely to live another decade without appreciable change to the markets. We would need a miracle, or better, a killer-app to budge the installed base.

Hence the cold-hearted analysis of cash-cow wins out.

But wait! The warm-blooded humanists won't let that happen for one and only one reason: it is simply too boring to contemplate. Microsoft has so many honest, caring, devoted techies within that if a decision were made to go cash-cow, there would be a mass-defection. So the question then arises, what sort of a hybrid will be acceptable to shareholders and workers? Taking a leaf from recent politics, which is going through a peak-energy-masquerade of its own these days, some form of "green platform" has appeal to both sides of the voting electorate.

DNS rebinding attack/patch: the germination of professional security cooperation?

Lots of chatter is seen in the security places about a patch to DNS coming out. It might be related to Dan's earlier talks, but he also makes a claim that there is something special in this fix. The basic idea is that DNS replies are now on randomised ports (or some such) and this will stop spoofing attempts of some form. You should patch your DNS.

Many are skeptical, and this gives us an exemplary case study of today's "security" industry:

Ptacek: If the fix is “randomize your source ports”, we already knew you were vulnerable. Look, DNS has a 16 bit session ID… how big is an ASPSESSIONID or JSESSIONID? When you get to this point you are way past deck chairs on the titanic, but, I mean, the web people already know this. This is why TLS/SSL totally doesn’t care about the DNS. It is secure regardless of the fact that the DNS is owned.

Paraphrased: "Oh, we knew about that, so what?" As above, much of the chatter in other groups is about how this apparently fixes something that is long known, therefore insert long list of excuses, hand-wringing, slap-downs, and is not important. However, some of the comments are starting to hint at professionalism. Nathan McFeters writes:

I asked Dan what he thought about Thomas Ptacek’s (Thomas Ptacek of Matasano) comments suggesting that the flaw was blown out of proportion and Dan said that the flaw is very real and very serious and that the details will be out at Black Hat. Dan mentioned to me that he was very pleased with how everything has worked with the multi-vendor disclosure process, as he said, “we got several vendors together and it actually worked”. To be honest, this type of collaboration is long overdue, and there’s a lot of folks in the industry asking for it, and I’m not just talking about the tech companies cooperating, several banking and financial companies have discussed forums for knowledge sharing, and of course eBay has tried to pioneer this with their “eBay Red Team” event. It’s refreshing to here a well respected researcher like Dan feeling very positive about an experience with multiple vendors working together (my own experience has been a lot of finger pointing and monkey business).

Getting vendors to work together is quite an achievement. Getting them to work on security at the same time, instead of selling another silver bullet, is extraordinary, and Dan should write a book on that little trick:

Toward addressing the flaw, Kaminsky said the researchers decided to conduct a synchronized, multivendor release and as part of that, Microsoft in its July Patch Tuesday released MS08-037. Cisco, Sun, and Bind are also expected to roll out patches later on Tuesday.

As part of the coordinated release, Art Manion of CERT said vendors with DNS servers have been contacted, and there’s a longer list of additional vendors that have DNS clients. That list includes AT&T, Akamai, Juniper Networks, Inc., Netgear, Nortel, and ZyXEL. Not all of the DNS client vendors have announced patches or updates. Manion also confirmed that other nations with CERTs have also been informed of this vulnerability.

Still, for the most part, the industry remains fully focussed on the enemy within, as exemplified by Ptacek's comment above. I remain convinced that the average "expert" wouldn't recognise a security fix until he's been firmly wacked over the head by it. Perhaps that is what Ptacek was thinking when he allegedly said:

If the IETF would just find a way to embrace TLS/X509 instead griping about how Verisign is out to get us we wouldn’t have this problem. Instead, DNSSEC tried to reinvent TLS by committee… well, surprise surprise, in 2008, we still care about 16 bit session IDs! Go Internet!

Now, I admit to being a long-time supporter of TLS'ing everything (remember, there is only one mode, and it is secure!) but ... just ... Wow! I think this is what psychologists call the battered-wife syndrome; once we've been beaten black and blue with x.509 for long enough, maybe we start thinking that the way to quieten our oppressor down is to let him beat us some more. Yeah, honey, slap me with some more of that x.509 certificate love! Harder, honey, harder, you know I deserve it!

Back to reality, and to underscore that there is something non-obvious about this DNS attack that remains unspoken (have you patched yet?), the above-mentioned commentator switched around 540 degrees and said:

Patch Your (non-DJBDNS) Server Now. Dan Was Right. I Was Wrong.

Thanks to Rich Mogull, Dino and I just got off the phone with Dan Kaminsky. We know what he’s going to say at Black Hat.

What can we say right now?

1. Dan’s got the goods. ...

Redeemed! And, to be absolutely clear as to why this blog lays in with slap after slap, being able to admit a mistake should be the first criteria for any security guy. This puts Thomas way ahead of the rest of them.

Can't say it more clearly than that: have you patched your DNS server yet?

German court finds Bank responsible for malwared PC

Spiegel reports that a German lower court ("Amtsgerichts Wiesloch (Az4C57/08)") has found a bank responsible for malware-driven transactions on a user's PC. In this case, her PC was infected with some form of malware that grabbed the password and presumably a fresh TAN (German one-time number to authenticate a single transaction) and scarfed 4000 euros through an eBay wash.

Unfortunately only in German, and so analysis following is highly limited and unreliable. It appears that the court's logic was that as the transaction was not authenticated by the user, it is the bank's problem.

This seems fairly simple, except that Microsoft Windows-based PCs are difficult to keep clean of malware. In this case, the user had a basic anti-virus program, but that's not enough these days (see top tips on what helps).

We in the security field all knew that, and customers are also increasingly becoming aware of it, but the question the banking and security world is asking itself is whether, why and when the bank is responsible for the user's insecure PC? Shouldn't the user take some of the risk for using an insecure platform?

The answer is no. The risk belongs totally to the bank in this case, in the opinion of the Wiesloch court, and the court of financial cryptography agrees. Consider the old legal principle of putting the responsibility with the party best able to manage it. In this case, the user cannot manage it, manifestly. Further, the security industry knew that the Windows PC was not secure enough for risky transactions, and that Microsoft software was the dominant platform. The banking industry has had this advice in tanker-loads (c.f. EU "Finread"), and in many cases banks have even heeded the advice, only to discard it later. The banking industry decided to go ahead in the face of this advice and deploy online banking for support cost motives. The banks took on this risk, knowing the risk, and knowing that the customer could not manage this risk.

Therefore, the liability falls completely to the bank in the basic circumstances described. In this blog's opinion ! (It might have been different if the user had done something wrong such as participate in a mule wash or had carried on in the face of clear evidence of infection.)

There is some suggestion that the judgment might become a precedent, or not. We shall have to wait and see, but one thing is clear, online banking has a rocky road ahead of it, as the phishing rooster comes home to roost. For contrary example, another case in Cologne (Az: 9S195/07) mentioned in the article put the responsibility for EC-card abuse with the customer. As we know, smart cards can't speak to the user about what they are doing, so again we have to ask what the Windows PC was saying about the smart card's activities. If the courts hold the line that the user is responsible for her EC-card, then this can only cause the user to mistrust her EC-card, potentially leading to yet another failure of an expensive digital signing system.

The costs for online banking are going to rise. A part of any solution, as frequently described by security experts, is to not trust widely deployed Microsoft Windows PCs for online banking, which in effect means PCs in general. A form of protection is fielded in some banks whereby the user's mobile phone is used to authenticate the real transaction over another channel. This is mostly cheap and mostly effective, but it isn't a comprehensive or permanent solution.

H4.2 -- Usability Determines the Number of Users

Last week's discussion (here and here) over how there is only one mode, and it is secure, brought forth the delicious contrast with browsing and security: yes, you can do that but it doesn't work well. No, I'm not talking about the logos being cross-sited, but all of the 100 little flaws that you find when you try and do a website for secure purposes.

So why bother? Financial cryptography eats its own medicine, but it doesn't do it for breakfast, lunch and desert. Which reminds me to introduce another of the sub-hypes for critique:

#4.2 Usability Determines the Number of Users

Ease of use is the most important determinant to the number of users. Ease of implementation is important, ease of incorporation is also important, and even more important is the ease of use by end-users. This reflects a natural subdivision into several classes of users: implementors, integrators and end-users, each class of which can halt the use of the protocol if they find it ... unusable. As they are laid out serially between you and the marketplace, you have to consider usability to all of them.

The protocol should be designed to be easy to code up, so as to help implementors help integrators help users. It should be designed to be easy to interface to, so as to help integrators help users. It should be designed to be easy to configure, so as to help users get security.

If there are any complex or tricky features, ask yourself whether the benefit is really worth the cost of coder's time. It is not that developers cannot do it, it is simply that they will not do it; nobody has all the time in the world, and a protocol that is twice as long to implement is twice as likely to not get done.

Same for integrators of systems. If the complexity provided by the protocol and the implementation causes X amount of work, and another protocol costs only X/2 then there is a big temptation to switch. Regardless of absolute or theoretical security.

Same for users.

The Dutch show us how to make money: Peace and Cash Foundation

Sometime around 3 years back, banks started to respond to phishing efforts by putting in checks and controls to stop people sending money. This led to the emergence of a new business model that promised great returns on investment by arbitraging the controls, and has led to the enrichment of many! Now, my friends in NL have alerted me to the NVB's efforts to sell the Dutch on the possibilities.

Welcome to the Peace and Cash Foundation!

A fun few minutes, and even though it is in Dutch, the symbology should be understood. Does anyone have an English translation?

(Okay, you might not see the Peace and Cash Foundation by the time you click on the site, but another generation will be there to help you to well-deserved riches...)

Case study in risk management: Debian's patch to OpenSSL

Ben Laurie blogs that downstream vendors like Debian shouldn't interfere with sensitive code like OpenSSL. Because they might get it wrong... And, in this case they did, and now all Debian + Ubuntu distros have 2-3 years of compromised keys. 1, 2.

Further analysis shows however that the failings are multiple, are at several levels, and they are shared all around. As we identified in 'silver bullets' that fingerpointing is part of the problem, not the solution, so let's work the problem, as professionals, and avoid the blame game.

First the tech problem. OpenSSL has a trick in it that mixed in uninitialised memory with the randomness generated by the OS's formal generator. The standard idea here being that it is good practice to mix in different sources of randomness into your own source. Roughly following the designs from Schneier and Ferguson (Yarrow and Fortuna), modern operating systems take several random things like disk drive activity and net activity and mix the measurements into one pool, then run it through a fast hash to filter it.

What is good practice for the OS is good practice for the application. The reason for this is that in the application, we do not know what the lower layers are doing, and especially we don't really know if they are failing or not. This is OK if it is an unimportant or self-checking thing like reading a directory entry -- it either works or it doesn't -- but it is bad for security programming. Especially, it is bad for those parts where we cannot easily test the result. And, randomness is that special sort of crypto that is very very difficult to test for, because by definition, any number can be random. Hence, in high-security programming, we don't trust the randomness of lower layers, and we mix our own [1].

OpenSSL does this, which is good, but may be doing it poorly. What it (apparently) does is to mix in uninitialised buffers with the OS-supplied randoms, and little else (those who can read the code might confirm this). This is worth something, because there might be some garbage in the uninitialised buffers. The cryptoplumbing trick is to know whether it is worth the effort, and the answer is no: Often, uninitialised buffers are set to zero by lower layers (the compiler, the OS, the hardware), and often, they come from other deterministic places. So for the most part, there is no reasonable likelihood that it will be usefully random, and hence, it takes us too close to von Neumann's famous state of sin.

Secondly, to take this next-to-zero source and mix it in to the good OS source in a complex, undocumented fashion is not a good idea. Complexity is the enemy of security. It is for this reason that people study the designs like Yarrow and Fortuna and implement general purpose PRNGs very carefully, and implement them in a good solid fashion, in clear APIs and files, with "danger, danger" written all over them. We want people to be suspicious, because the very idea is suspicious.

Next. Cryptoplumbing involves by its necessity lots of errors and fixes and patches. So, bug reporting channels are very important, and apparently this was used. Debian team "found" the "bug" with an analysis tool called Valgrind. It was duly reported up to OpenSSL, but the handover was muffed. Let's skip the fingerpointing here, the reason it was muffed was that it wasn't obvious what was going on. And, the reason it wasn't obvious looks like the code was too clever for its own good. It tripped up Valgrind (and Purify), it tripped up the Debian programmers, and the fix did not alert the OpenSSL programmers. Complexity is our enemy, always, in security code.

So what in summary would you do as a risk manager?

1. Listen for signs of complexity and cuteness. Clobber them when you see them.
2. Know which areas of crypto are very hard, and which are "simple". Basically, public keys and random generation are both devilish areas. Block ciphers and hashes are not because they can be properly tested. Tune your alarm bells for sensitivity to the hard areas.
3. If your team has to do something tricky (and we know that randomness is very tricky) then encourage them to do it clearly and openly. Firewall it into its own area: create a special interface, put it in a separate file, and paint "danger, danger" all over it. KISS, which means Keep the Interface Stupidly Simple.
4. If you are dealing in high-security areas, remember that only application security is good enough. Relying on other layers to secure you is only good for medium-level security, as you are susceptible to divide and conquer.
5. Do not distribute your own fixes to someone else's distro. Do an application work-around, and notify upstream. (Or, consider 4. above)
6. These problems will always occur. Tech breaks, get used to it. Hence, a good high-security design always considers what happens when each component fails in its promise. Defence in depth. Systems that fail catastrophically with the failure of one component aren't good systems.
7. Teach your team to work on the problem, not the people. Discourage fingerpointing; shifting the blame is part of the problem, not the solution. Everyone involved is likely smart, so the issues are likely complex, not superficial (if it was that easy, we would have done it).
8. Do not believe in your own superiority. Do not believe in the superiority of others. Worry about people on your team who believe in their own superiority. Get help and work it together. Take your best shot, and then ...
9. If you've made a mistake, own it. That helps others to concentrate on the problem. A lot. In fact, it even helps to falsely own other people's problems, because the important thing is the result.

[1] A practical example is that which Zooko and I did in SDP1 with the initialising vector (IV). We needed different inputs (not random) so we added a counter, the time *and* some random from the OS. This is because we were thinking like developers, and we knew that it was possible for all three to fail in multiple ways. In essence we gambled that at least one of them would work, and if all three failed together then the user deserved to hang.

Phishing faceoff - Firefox 3 v. the market for your account

Dria writes up a fine intro to the new Firefox security UI, the thing that forms the front line for phishing protection.

Basically, the padlock has been replaced with a button that shows a "passport" icon in multiple colours and with explanatory text. Pretty good, although as far as I can see, this means you can no longer *look* and tell what is going on. OK, I'll run with that as an experiment! For now, there are 4 colours: grey, blue, green and yellow. Grey is for no identity, and I guess that also means no TLS although it isn't that clear as encryption edge-cases are not shown. Blue is Good, being the conventional browser security level, and Green is the EV colour for their new enhanced "better than before" identity verification.

One minus: yellow is now a confusing colour. Before it was the colour of success, now it is the colour of failure (although that failure is easily rectified by clicking to add an exception). As I commented before, we do need the colours to be re-aligned after a period of experimentation. Kudos to Firefox team for taking that one on the chin, if only others were prepared to clearly unwind some well-meaning ideas...

Second Minus: As many said in comments, the "invalid identity verification" isn't always that, sometimes it is a non-third-party verification. This needs to be distinguished between "identity not 3rd-party verified" and "self-verified."

Indeed, our old friend, the self-identified or self-signed certificate, is widely used in technical community for local and small scale security systems, so we can see the message "not trusted" and "invalid" are simply wrong. Now, Jonath says that Firefox is planning to do Key Continuity Management, so it may be that the confusing messages get cleaned up then. (I don't know if anyone else has spotted the nexus, but when we take KCM and combine it with 3rd party verifications, sometimes called variously TTP or CVP or certificate authorities, then we get the best of both worlds. It will eventually come, because it is so sensible.)

One Good Plus: the CA is displayed in all cases where the certificate information is available. This is exceedingly important because it is the CA that does the verification of identity; Firefox only repeats it (which is why the "trusted" message is soooo wrong). Slowly but surely, we have to move the browser UI to pin the assertation on the CA, and we have to move the user to thinking about CAs as competing, branded entities that stand behind their statements. Publically. At least, Firefox has not made the mistake that Microsoft has made with the new IE, which displays the name of the authority in some circumstances, but not others.

It is important to realise: we can take a few missteps along the way, such as Gerv's noble attempt with the colour yellow. It is very costly to get these UIs built, trialled and tuned, so any experiments have to be taken with an expectation of more improvement in the future. As long as we're moving forward, things are getting better.

What's all this about? Why is it important? Pop over to Francois' post on stolen accounts to see the real reason:

(Hat tip to Gunnar again.) Them's hard numbers! A quick eyeball calculation over Francois's numbers reveals that the going price of a well-funded account is 8% of the value. This makes some sense, because getting access to the account details is easy, it's done in bulk, given that the security systems of online banks are so fundamentally and hopelessly flawed. What is more difficult is getting the money out, because, since the arisal of phishing, and the sticking of some of the liability, occasionally, to the banks, the online security teams have done some things to make it a little trickier. So the lion's share goes to the money launderer, who needs to pay a lot more in direct costs to get his hard-stolen loot out.

How does this relate to Firefox? Phishing arose as an attack on the browser's security UI, so the Firefox team are working to address that issue with KCM, better displays of the CA name that makes the claim, and more clear symbols. The first 2 images above may help you to avoid the 3rd image.

Unfortunately, the big picture overtook the browser world, so the work is only just starting. Phishing caused massive funds to flow into the attackers, so they invest in any attacks that might return more value. Especially, the attack profile now includes MITM and trojans, so hardening of the browser against inside attacks will be increasingly necessary.

Remember, the threat is on the node, not on the wire; which gives us an answer to the question that Jonath was posing: Hardening against inside attacks should be on the agenda for future Firefox.

Paypal -- Practical Approaches to Phishing -- open white paper

Paypal has released a white paper on their approach to phishing. It is mostly good stuff. Here are their Principles:

1. No Silver Bullet -- We have not identified any one solution that will single-handedly eradicate phishing; nor do we believe one will ever exist. ...

2. Passive Versus Active Users -- When thinking about account security, we observe two distinct types of users among our customers. The first and far more common is the “passive” user. Passive users expect to be kept safe online with virtually no involvement of their own. They will keep their passwords safe, but they do not look for the “s” in https nor will they install special software packages or look for digital certificates. The active user, on the other hand, is the “see it/touch it/use it” person. They want two-factor authentication, along with every other bell and whistle that PayPal or the industry can provide. Our solution would have to differentiate between and address both of these groups.

3. Industry Cooperation -- PayPal has been a popular “target of opportunity” for criminals due to our large account base of over 141 million accounts2 and the nature of our global service. However, while we may be an attractive target, we are far from the only one. Phishing is an industry problem, and we believe that we have a responsibility to help lead the industry toward solutions that help protect consumers – and the Internet ecosystem as a whole.

4. Standards-based -- A preference for solutions based on industry standards could be considered a facet of industry cooperation, but we believe it’s important enough to stand on its own. If phishing is an industry problem, then industry standard solutions will have the widest reach and the least overhead – certainly compared to proprietary solutions. For that reason, we have consistently picked industry standard solutions.

(Slightly edited.) That's a good start. The white paper explores their strategy, walks through their work with email signing. Short message: tough! No mention of the older generation technologies such as OpenPGP or S/MIME, but instead, they create plugins to handle their signatures:

To reach the active users who do not access their email through a signature-rendering email client, PayPal started working with Iconix, which offers the Truemark plug-in for many email clients. The software quickly and easily answers the question of “How do I know if a PayPal email is valid?” by rewriting the email inbox page to clearly show which messages have been properly signed.

That's by way of indicating how poorly tools designed in the early 90s from poor security analysis and wrong threat models are coping with real threats.

Next part is their work with the browser. It starts:

4.1 Unsafe browsers

There is of course, a corollary to safer browsers – what might be called “unsafe browsers.” That is, those browsers which do not have support for blocking phishing sites or for Extended Validation Certificates (a technology we will discuss later in this section). In our view, letting users view the PayPal site on one of these browsers is equal to a car manufacturer allowing drivers to buy one of their vehicles without seatbelts. The alarming fact is that there is a significant set of users who use very old and vulnerable browsers, such as Microsoft’s Internet Explorer 4 or even IE 3. ...

Unsafe Browsers are a frequent complaint here and in other places. Some good stuff has been done, but it was too little, too late, and we now see the unfortunate damage that has been done. One of these effects was that it is now up to the big website operators, in this case PayPal, to start policing the browsers. Old versions of IE are to be blocked, and a recent warning shot indicates that browsers that don't support EV will be next.

Next point: Paypal worked through several strategies. Three years ago, they pushed out a Toolbar (similar to the one listed on this blog). However this only works for those who download toolbars, a complaint frequently mentioned. So then Paypal, shifted to working with Microsoft to adopt the technology into IE7, and now they have ridden the adoption curve of IE7 for free.

Again this is exactly what should have been done: try it in toolbars then adopt it in the browser core. A cheap hint was missed and an expensive hit was scored:

4.4 Extended Verification SSL Certificates

Blocking offending sites works very well for passive users. However, we knew we needed to provide visual cues for our active users in the Web browser, much like we did with email signatures in the mail client.
Fortunately, the safer browsers helped tremendously. Taking advantage of a new type of site certificate called ‘Extended Validation (EV) SSL Certificates,’ newer browsers such as IE 7 highlight the address bar in green when customers are on a Web site that has been determined legitimate. They also display the company name and the certificate authority name. So, by displaying the green glow and company name, these newer browsers make it much easier for users to determine whether or not they’re on the site that they thought they were visiting.

This is a mixture of misinformation and danger for PayPal. The good part is that the browser, which is the authority on the CAs, now states definitively "Which Site" and also "Who says!" Green is a nice positive colour, too.

So, when this goes wrong, as it will, the user has more information in order to seek solutions. This shifting of the information back to the user (whether they want it or not) will do much more to causing the alignment of liabilities.

The bad part is that the browsers did not need a proprietary solution dressed up in a consortium in order to do this. They had indeed added the colour yellow (Firefox) and company name themselves, and the CA name has been an idea that I pushed repeatedly. For the record, Verisign asked for it early on as well. There's nothing special in the real business world about asking for "who says so?"

So we now have a structural lock-in placed in the browsers which they could have done for free, on their own initiative. Where does this go from here? Well, it certainly helps PayPal in the short term (in the same way that they could have said to users "download Firefox, check the yellow bar and company name"). But beyond that, I see dangers. As I have frequently written about the costs of the security approach before, I'll skip it now.

Overall, though, I'm pleased with the report. They have recognised that the industry has no solutions (no "silver bullets") and they have to do it themselves. They've implemented many different strategies, discarded some and improved others. Did it work? Yes, see the graph.

Best of all, they've taken the wraps off and published their findings. One of the clear indications from recent research and breach laws is that opening up the information is critical to success, and that starts with the website people. It's your job, do it, but that doesn't mean you have to do it alone! You can help each other by sharing industry-validated results, which are the only ones of any value.

To conclude, there are some other strategies that I'll suggest, and if PayPal are reading this, then they too can ask what's going on here:

a. Get TLS/SNI into Apache and IIS. Why? So that virtual hosted sites -- the 99% -- can use TLS. This will lead grass-roots-style to an explosion in the use of TLS.

Why's that helpful? (a) it will raise the profile of TLS work enourmously, and that includes server-side and browser-side practices. It will help to re-direct all these resources above into security work in the browser. Right now, 1% of activity is in TLS. Priorities will change dramatically when that goes to 10%, and that means we can count on the browser teams to spend a whole lot more time on it. And (b) if all traffic goes over TLS, this reduces the amount of security work quite considerably because everything is within the TLS security model. Paypal already figured this as "more or less all" their stuff is now under TLS, including the report!

All browsers have already done their bit for TLS/SNI. Webservers are the laggards. Ask them.

b. Hardened browser. Now that Firefox, IE and others have done some work to push attacks away from the user, the phishers are attacking the browsers from the inside. So there is a need to really secure the inside against attacks. Indeed Paypal already noted it in the report.

c. Hardened website. This means *reducing the tech.* The more you please your users, the more you please your attackers.

d. 2-channel authentication over the transaction. Okay, that's old news, but it bears repeating, because my online payment provider can only give me one of those old RSA fobs.

e. The browser website interface is here to stay. Which means we are stuck with a pretty poor combination. What's the long term design path? Here's one view: it starts with client-side certificates and opportunistic cryptography. Why? Because otherwise, transactions are naked and vulnerable, and your efforts are piecemeal.

Which means, don't replace the infrastructure wholesale, but re-tune it in the direction of security. Read the literature on secure transactions, none of it was ever employed in ecommerce, so it means there are lots of opportunities left for you :)

(Firefox and IE are both doing early components in this area, so ask them what it's about!)

f. Finally, bite the bullet and understand that your users will revolt one day, if you continue to keep fees high through industry-wide cooperation on lackadaisical fraud practices. High fraud and high loss means high fees which means high profits. One day the users will understand this, and revolt against your excuse. The manner this works is already well known to PayPal and it will happen to you, unless you adopt a competitive approach to fraud and to fees.

Fair Disclosure via blogs? Anyone listening to Pow, Splat, Blech?

Another message via the medium, this time from someone who knows how to use a remailer, and is therefore anonymous:

Don't try this at home! (without an anonymizing proxy, anyway)

Google willingly gives anyone a list of highly vulnerable US Government websites. Just write the following into the search box:

gimme pow that do some splat

These are sites that construct blah directly from blech. Most of them would respond to blah that are not supported by the blech-based interface, leaking sensitive information left and right. But quite a few would let you splat the splotches as well, up to and including blamming entire ker-blats.

You didn't hear it from me.

OK, that was fun. Problem now is, how does someone I don't know that won't hear it from me get it from someone I didn't hear it from?

---

Late Addition: Now that anon has leaked the sensitive command, I realise this is what I first saw on Perilocity's post on WTF. Breach news is worse than politics, a week is ancient history. I can do no better than those guys. Still, to save a click, the basic thing is that you can see the SELECT command on the HTML of the website, and then use that example to craft your own. Here's a story of some sick public servants who Oklahoma city felt the need to share with us all:

Here's the rest of the message. I think we should all try it. Safety in numbers.

Just write the following into the search box:

allinurl:.gov select from where

These are websites that construct SQL queries directly from the URL. Most of
them would respond to queries that are not supported by the web-based UI of
the website, leaking sensitive information left and right. But quite a few
would let you modify the databases as well, up to and including dropping
entire tables.

The only question left is whether I'm not hearing from one anonymous or two? But you're not asking that.

Proving that you know something about security...

I recently received an (anonymous) comment on the 'silver bullets' paper that ran like this:

Sellers most certainly still have more information than the vast majority of buyers based on the fact that they spend all of their time making security software.

That's an important statement, and deserves to be addressed. How can we check that statement? Well, one way is that we could walk over to the world's biggest concentration of sellers and perhaps buyers, and test the waters? The RSA conference! Figuratively, blog-wise, Gunnar does just that:

I went to RSA to speak with Brian Chess on Breaking Web Services. First time for me to RSA, I generally go to more geek-to-geek conferences like OWASP. It is a little weird to be in such a big convention. There were soooo many vendors yet most of the products in the massive trade show floor would have as much an impact on the security in your system as say plumbing fixtures. What is genuinely strange to me is that every other area in computers improves and yet security stagnates. For years the excuse that security people gave for their field's propensity to lameness is that "no one invests a nickel in security." However, that ain't the case any more and yet most of the products teh suck. This doesn't happen in other areas of computing - databases are vastly better than a decade ago, app servers same, OS same, go right down the list. What gives in security? Where is the innovation?

This is more or less similar to the paper's selection of quotes. Anecdotally, evidence exists that insiders don't think sellers know enough, on both sides of the fence. However, surveys can be self-selecting (as was my sample of quotes in the paper), and opinions can be wrong. So it is important to realise that we have not proven one way or another, we've simply opened the door to an uncertainty.

That is, it could be true that sellers don't know enough! How we then go on to show this, one way or another, is a subject for other (many) posts and possibly much more academic research. I don't for a moment think it is reasonable nor scientifically appropriate to prove this in one paper.

another way to track their citizens

Passports were always meant to help track citizens. According to lore, they were invented in the 19th century to stop Frenchmen evading the draft (conscription), which is still an issue in some countries. BigMac points to a Dutch working paper "Fingerprinting Passports," that indicates that passports can now be used to discriminate against the bearer's country of issue, to a distance of maybe 25cm. Future Napoleons will be happy.

Because terrorising the reader over breakfast is currently good writing style by governments and media alike, let's highlight the dangers first. The paper speculates:

Given that we can remotely detect the presence of a passport of a particular country, how could this functionality be abused? One abuse case that has been suggested is a passport bomb, designed to go off if someone with a passport of a certain nationality comes close. One could even send such a bomb by post, say to an embassy. A less spectacular, but possibly more realistic, use of this functionality would by passport thieves, who can remotely check if someone is carrying passport and if it is of a ‘suitable’ nationality, before they decide to rob them.

From the general fear department, we can also add that overseas travellers sometimes have a fear of being mugged, kidnapped, hijacked or simply shot because of their mere membership of a favourable or unfavourable country.

Now that we have the FUD off our chest, let's talk details. The trick involves sending a series of commands (up to 4) to the RFID in the passport, each of which are presumably rejected by the passport. The manner of rejection differs from country to country, so a precise fingerprint-of-country can be formed simply by examining each rejection, and then choosing a different command to further narrow the choices.

How did this happen? I would speculate that the root failure is derived from bureaucrats' never-ending appetite for complex technological solutions to simple problems. In this case, the first root cause is the use of the RFID, being by intention and design something that can be read from up to 10 cm.

It is inherently attackable, and therefore by definition a very odd choice for security. The second complexity, then, involved implementing something to stop the attackers reading off the RFIDs without permission. The solution to an active read-off attack is encryption, of course! Which leads to our third complexity, a secret key, which is written inside the passport, of course! Which immediately raises issues of brute-forcing (of course!) and, as the paper references, it turns out, brute forcing attacks work on some countries' passports because the secret key is .. poorly chosen.

All of this complexity, er, solution, means something called Basic Access Control is added to the RFID in order to ensure the use of the secret key. Which means a series of commands meant to defend the RFID. If we factor in the tendency for each country to implement passports entirely alone (because they are more scared of each other than they are of their citizens), we can see that each solution is proprietary and home-grown. To cope with this, the standard was written to be very flexible (of course!). Hence, it permits wide diversity in response to errors.

Whoops! Security error. In the world of security, we say that one should be precise in what we send, and precise in what we return.

From that point of view, this is poor security work by the governments of the world, but that's to be expected. The US State Department can now derive some satisfaction from earlier blunders; because of their failure to implement any form of encryption or access control, American passports can be read by all (terrorists and borderists alike), which apparently forced them to add aluminium foil into the passport cover to act as a Faraday cage. Likely, the other countries will now have to follow suit, and the smugness of being sophisticated and advanced in security terms ("we've got BAC!") will be replaced by a dawning realisation that they should have adopted the simpler solutions in the first place.

Pogo reports: big(gest) bank breach was covered up?

An anomoly surfaces on the breach scene. Lynn reports in comments via dark reading to Pogo:

With the exception of the Birmingham News, what may be the largest bank breach involving insider theft of data seems to have flown under the mainstream media radar. ...

In light of the details now available, the breach appears to be the largest bank breach involving insider theft of data in terms of number of customers whose data were stolen. The largest incident to date for insider theft from a financial institution involved the theft of data on 8.5 million customers from Fidelity National Information Services by a subsidiary's employee.

It is not clear at the time of this writing whether Compass Bank ever notified the more than 1 million customers that their data had been stolen or how it handled disclosure and notification. A request for additional information from Compass Bank was not immediately answered.

I would guess that the Feds agreed to keep it quiet. And gave the institution a get-out-of-jail card for the disclosure requirement. It would be curious to see the logic, and I'd be skeptical. On the one side, the damage is done, and the potential for a sting or new information would not really be good enough to compensate for a million victims.

On the other side, maybe they were also able to satisfy themselves that no more damage would be done? It still doesn't cut the mustard, because once identity victims get hit, they need the hard information to clear their credit records.

But, in the light of yesterday's post, let's see this as an exception to the current US flavour of breach disclosure, and see if it sheds any light on costs of non-disclosure.

Trojan with Everything, To Go!

more literal evidence of ... well, everything really:

Targeting over 400 banks (including my own :( ! ) and having the ability to circumvent two-factor authentication are just two of the features that push Trojan.Silentbanker into the limelight. The scale and sophistication of this emerging banking Trojan is worrying, even for someone who sees banking Trojans on a daily basis.

This Trojan downloads a configuration file that contains the domain names of over 400 banks. Not only are the usual large American banks targeted but banks in many other countries are also targeted, including France, Spain, Ireland, the UK, Finland, Turkey—the list goes on.

The ability of this Trojan to perform man-in-the-middle attacks on valid transactions is what is most worrying. The Trojan can intercept transactions that require two-factor authentication. It can then silently change the user-entered destination bank account details to the attacker's account details instead. Of course the Trojan ensures that the user does not notice this change by presenting the user with the details they expect to see, while all the time sending the bank the attacker's details instead. Since the user doesn’t notice anything wrong with the transaction, they will enter the second authentication password, in effect handing over their money to the attackers. The Trojan intercepts all of this traffic before it is encrypted, so even if the transaction takes place over SSL the attack is still valid. Unfortunately, we were unable to reproduce exactly such a transaction in the lab. However, through analysis of the Trojan's code it can be seen that this feature is available to the attackers.

The Trojan does not use this attack vector for all banks, however. *It only uses this route when an easier route is not available*. If a transaction can occur at the targeted bank using just a username and password then the Trojan will take that information, if a certificate is also required the Trojan can steal that too, if cookies are required the Trojan will steal those....

(spotted by JPM) MITB, MITM, two-factor as silver bullets for online banks, the node is insecure, etc etc.

About the only thing that is a bit of a surprise is the speed of this attack. We first reported the MITB here around 2 years back, and we are still only seeing reports like the above. Although I said earlier that a big problem with the banking world was that the attacker can spin inside your OODA loop, it would appear that he does not take on every attack.

See above for some limits: the attacker is finding and pursuing the attacks that are easiest, first. Is this finally the evidence that cryptographers cannot ignore? Crypto alone has proven to not work. It may be theoretically strong, but it is practically brittle, and easily bypassed. A more balanced, risk-based approach is needed. An approach that uses a lot less crypto, and a lot more engineering and user understanding, would be far more efficacious to deliver what users need.