Extended Subset

Recently a leading expert was interviewed on topics involving data security and SSL. I feel that some of the statements made in that interview are misleading and need a little clarification (inline).

We’ve also seen Secure Sockets Layer (SSL) come under attack, and some experts are saying it is useless. Do you agree?

I’m not convinced that SSL has a problem. After all, you don’t have to use it.

WTF? Maybe this is out of context.

If I log-on to Amazon without SSL the company will still take my money.

No, I just tested it. Amazon will not let you log in without https. Good for them!

The problem SSL solves is the man-in-the-middle attack with someone eavesdropping on the line.

A MitM attack is different than passive eavesdropping. If you only needed to defend against a passive eavesdropper, that can be done with anonymous cryptography and you wouldn’t need the expense and complexity of maintaining PKI and the whole Certificate Authority industry. SSL/TLS is intended to provide protection from both kinds of attack.

But I’m not convinced that’s the most serious problem. If someone wants your financial data they’ll hack the server holding it, rather than deal with SSL.

Just because something isn’t the most serious problem in one scenario doesn’t mean it’s not a critical factor in the security equation. It may even be the most serious problem in some other scenario. SSL generally does its job much better than other components of the system, but that doesn’t mean problems with it should be tolerated.

But doesn’t SSL give consumers confidence to shop online, and thus spur e-commerce?
Well up to a point, but if you wanted to give consumers confidence you could just put a big red button on the site saying ‘You’re safe’. SSL doesn’t matter. It’s all in the database. We’ve got the threat the wrong way round. It’s not someone eavesdropping on Eve that’s the problem, it’s someone hacking Eve’s endpoint.

There’s the old joke about the two hunters running from a bear. (In case you haven’t heard it, one of them notes with irony that the race is between the two of them, rather than between them and the bear.) While this is an insightful analogy in many situations, the analogy only holds when there is only one bear who will be satisfied after only one target. This is certainly not the case in data security where there is likely more than one attacker who likely has more than one objective.

When are we going to get past this skewed view that data security only has to do with e-commerce web servers and their databases? Sure, it’s a common and important scenario, but it’s not the defining scenario for any core internet protocol. Without a solid library of primitive operations that deliver on their stated guarantees, it’s just not possible to build the larger and more complex systems securely.

What about how mail servers talk to each other? What about how B2B data exchange systems work? How do these endpoint systems receive their software patches and anti-malware updates? How do electronic voting machines transmit their results? All of these systems and many more can use SSL/TLS as a integral part of their security architecture.

We mustn’t dismiss the critical importance of SSL/TLS simply because web apps are prone to SQL injections and users don’t seem to be able to type “https” consistently. Some systems actually do have careful and competent designers and are deployed and managed by careful and competent admins. We need to hold the highest standards for core protocols like SSL/TLS, because if these people can’t build secure systems on top of them, what hope does anyone else have?

Much is being made about somebody with an authenticator getting their World of Warcraft account hacked: Man in the middle attacks circumventing authenticators.

From the original poster:

I was online, got a memory access violation critical error. Not being all to savvy with this, I didn’t pay extra attention to it.

This doesn’t sound like a man-in-the-middle attack to me. This sounds like a good old-fashioned compromised endpoint. An pwned box, if you will.

A MitM attack involves an active attacker who views and changes messages on the communications link between two endpoints. Any attack involving a compromise of the endpoint itself is, by definition, something else.

No login authentication scheme can help this. The legitimate user was, after all, logging in. The fact that his authentication keystrokes were being forwarded to the bad guys is just a technicality. It was effectively just a bandwidth-saver for the bad guys, who could have viewed his screen remotely and injected their own keystrokes and after he had logged in. Although one suspects that driving his character to the bank and mailing out all the valuable magic items might have prompted the user to turn off the PC!

Steve Dispensa and I gave the keynote presentation at Shmoocon this year. We spoke about our experiment in vulnerability disclosure, code named ‘Project Mogul’.

Video the talk is now avaliable at the Shmoocon site. (I suspect that link will break when they rework the site in preparation for 2011.)

Slides are at that site as well, but you might prefer the PDF version here.

Yesterday I read about the availability of a new version of Mozilla Thunderbird, which is all-around a pretty decent mail client. The new version is 3.0.x, and I’m currently using 2.0.x, so I figured it was due for an upgrade. I downloaded the new installer, uninstalled the previous version, and launched the installer. Everything appeared to be going fine.

Probably when the installer finished it offered to “Launch Thunderbird now”, and I took it up on the offer. For some reason, Thunderbird opened with an empty configuration, i.e., none of the mail accounts I had set up under 2.0.x were listed. I remembered having had previously been offered to “import settings” every other time I had installed a Mozilla product, so I launched that wizard. When it got to the step where I was supposed to select the application from which to import settings, the dialog box was blank and only the ‘Cancel’ button was enabled.

Although I felt it was a little strange that Thunderbird would not be able to keep its settings across an upgrade, I decided to press on. After all, I switch operating systems often enough that I usually end up redoing all that config once in a while anyway. So I selected ‘File’ -> ‘New’ -> ‘Mail’. The resulting dialog asked me just three questions: name, email address, and password. I became slightly suspicious when I noticed that the font sizes on the buttons didn’t match, but little did that prepare me for what happened next…

I am dumbstruck to see the the dialog box enlarge and display changing hostnames and port numbers which have no basis in reality. They are simply variations on a theme: my email address’ hostname with various mail-related prefixes and protocols attached. Essentially, it was doing a port scan against my domain. I knew that this port scan could have but one sinister purpose: to transmit my password to whomever was willing to pick up on the other end of the line!

Hostnames looked up:

    imap.example.com
    smtp.example.com
    pop.example.com
    pop3.example.com
    mail.example.com
    example.com

Ports probed:

    tcp port 143 imap
    tcp port 993 imaps
    tcp port 587 submission?
    tcp port 465 smtps
    tcp port 25 smtp
    tcp port 110 pop3
    tcp port 995 pop3s

Since not everyone is deeply familiar with the protocols involved here, I will point out the problem in case you haven’t guessed it. These are classic protocols used for transferring email. Like most older protocols, they were originally specified to transfer the password in-the-clear, and all of them have had some degree of protection for it added later. This has resulted in a situation where multiple versions of each protocol exist, sometimes simply wrapped in SSL/TLS and run on a different port number, and sometimes a negotiation is made to upgrade the security of a connection made to the original port. If the attacker can simply disrupt access to the secure connection, the application is induced to transmit the credentials over the insecure one. This is the crudest form of downgrade attack.

I also tried accounts for a couple of popular free email providers, Gmail and GMX. Interestingly, this detection process returned instantly even with a bad password and blocked connection. They both supported SSL/TLS unequivocally. Perhaps these providers have registered for special handling in Thunderbird (and in so doing increased the effective security for their users).

Admittedly, this auto-detection scheme probably looked dynamite to the user interface designers at Mozilla wanting to improve the experience. But (bless their hearts) it is quite the security bungle.

Thunderbird - It’s All Yours [mozillamessaging.com]

Easier to Get Started
All you need to provide is your name, email address, and password and Thunderbird will find your email settings and set up your email accounts for you. It’s that easy.

The generous explanation is that security concerns were weighed against usability concerns, and after soul-searching deliberation it was felt that, on balance, this represented a net improvement for their users. (A common mistake in security design is modeling the user as an aggregate statistic.) Some other explanations are that they didn’t think of the security concerns, the concerns didn’t come from influential parts of the organization, or they dismissed them out-of-hand because they just don’t care that much. I have no idea.

Of course there was no way it was going to arrive at reasonable settings for my single-user domain, I tunnel all that stuff over SSH and don’t have the ports listening. But Thunderbird gave me no informed consent before it started poking around for insecure connections to make, and even if it had managed to auto-detect some usable set of connection parameters, I assume it wouldn’t have explained the risks of using them. Given the protocols involved,  it must have been willing to leak the credentials in order to determine if the parameters were usable.

It may be that the auto-detection logic doesn’t actually use your password. I didn’t actually set up insecure servers to verify that either way. Regardless, it is not a difference in practice since the password must obviously be transmitted the first time it is used.

I find this somewhat non-intuitive, but really the only secure way to configure these email settings is to have them conveyed from your email admin all the way to your mail client via a trusted channels of communication. The actual admin is able to tell you “this is the name to use for the mail server and be sure to check the box that says ‘require SSL/TLS’”. But no auto-detection scheme can know to check that box.

http://www.wired.com/threatlevel/2010/02/school-district-halts-webcam-surveillance/

http://lmsd.org/sections/news/default.php?m=0&t=today&p=lmsd_anno&id=1138

Dear Dr. McGinley,

I am very curious to find the answer to this question: what kind of diseased mind comes up with a scheme involving sending remote-controlled cameras into the homes of schoolchildren?

Is audio transmission or recording (e.g. microphones) part of this system’s capabilities too?

In your letter, you write:

This feature was only used for the narrow purpose of locating a lost, stolen or missing laptop.

What kind of ethical system were you able to construct in which those trivial ends could be used justify such sinister means?

Did you personally endorse this, or just assent in silence?

Sincerely,

Marsh Ray

Caught the last few minutes of this talk at Black Hat DC yesterday.

Computerworld has a nice summary article with some quotes and an explanation of the scope of the break.

But really, this once sentence captures it:

“Tarnovsky’s examination process involved subtle use of hardware-based liquid chemical and gas technologies in a lab setting to probe with specialized needles to build tungsten bridges.”

The reverse engineer always wins.

I also spoke with someone who knows about the technology in the new DVDs. It seems the rippers usually crack the decryption within a few weeks of each major release. At best, the encryption buys some time for disc sales to make their initial profit. This industry has learned by now not to attempt the impossible (selling millions of discs of data for special-purpose computers without it also ending up on general-purpose computers). Instead, their strategy seems to be to structure the pace of their defeat well enough for it to be economically discounted. I think this is very wise.

Consider this the next time someone proposes a DRM solution to restore the economics of scarcity to a blob of computer data!

Impervia has released an interesting study of 32M user passwords obtained incidental to a data breach. We’re used to this kind of thing by now, I suppose. But in any case it appears that only 0.2% of user accounts had passwords meeting their minimum criteria for a “strong” password:

• Eight or more characters
• Some mixture of the basic character classes: upper- and lower-case, digits, and symbols.

We’ve been hearing this advice for years. In fact, it’s now recommended practice for new password entry text fields to enforce some minimal complexity requirements. Looking at the “top 20″ list of common passwords, anything would be an improvement.

But are mechanical complexity requirements always enhance security? More importantly, is it possible that they could actually decrease security for careful and conscientious users who choose reasonable passwords in the first place?

Consider Schneier’s example password from the report. Distilled from a pass phrase, it comes out as “tlpWENT2m”. For most systems, I like to use the pwgen utility to generate reasonably good passwords. For example, it just suggested the password “Aisah4ahw7″ (I agree they should be written down and managed with careful physical security).

These example passwords have 9 or 10 characters with apparently good probabilities of encountering capital letters and digits. The upper- and lower-case letters and digits amount to 62 possibilities for each character, putting a hard upper limit on the entropy of about 6 bits per character. At 10 characters in length, we could theoretically approach 60 bits of total entropy in our password! “Good enough for government work” as they say. Or at least it used to be.

So what happens when a well-intentioned user interface rejects our thoughtfully-chosen password on the basis that “it must contain a symbol”? Assume that the user has already chosen the password they want to use and has written it down, and it’s otherwise a good one. Perhaps also the UI enforces the recommendation (the report attributes this to NASA) that “if there is only one letter or special character, it should not be either the first or last character in the password.” My guess is that most users at this point get out the eraser and replace one of the characters with a symbol in order to satisfy the rule.

But herein lies a problem: On my (typical US) keyboard there are only 32 choices for symbol characters. In addition, UI text fields have a reputation for rejecting (or silently munging) quote-like or escape-like characters which probably rules out some of the more interesting choices. We have just reduced the maximum entropy contributed by that character from 6 to 5 bits!

But you forgot to consider … Yes, there are a number of holes with this theory.  Lacking any more interesting rhetorical device at the moment, I’ll pretend to discuss them with myself. Here are a few I can think of:

• Those example passwords were derived from rules for English text in one way or another. They won’t be anywhere close to theoretical maximum entropy. - True, but neither will the replacement symbol. More than likely the user will simply replace an ‘a’ with an ‘@’ or some such change. Note the sample characters in the recommendation: !@#$%^&*,;” Even those authors seem to like to type “123456″!
• The user has some freedom to choose which of the characters he will replace with the symbol. - Applying all the “best practices” to the ten character password leaves eight options. Potentially, this could represent three bits of added entropy and in fact push the symbol requirement into a net gain.
• The user could add or change more than one symbol. - Sure, the user has just been required to type one digit, one uppercase letter, one lowercase letter, and five other chars. How much more tricky typing are they likely to be in the mood to add? Oh, and they have to type it perfectly twice in a row right now, and an indefinite number of times in the future.

So this analysis is largely inconclusive. Adding a new password complexity requirement may increase the effective entropy somewhat, but there may even be cases where it decreases it. What is clear though is that there is no set of practical, enforceable requirements that can magically take the users from dictionary words to that perfect, even distribution over the 94^10 = 5e19 possible passwords.

But above all, look out for the law of unintended consequences. Especially when feeling the urge to subject us humans to new sets of rigid mechanical rules, however great they might seem on paper.

DReaM-Cache: Distributed Real-Time Transaction Memory Cache to Support Two-Factor Authentication Services and its Reliability

Here’s a paper we (PhoneFactor and UMKC) will be presenting at IEEE NOMS 2010 in April.

It gives an overview and an in-depth reliability analysis of a distributed real-time transactional data store we developed in support of the PhoneFactor back-end systems. It’s superficially similar to memcached, except that it’s highly available rather than scalable.

We originally called the system “cloud” internally, and still do. Unfortunately though that term has been so hyped-up in the last few years (for something else entirely) that we had to come up with another name for the paper.

• SteveD has posted an experimental patch for GNUTLS
• Unfortunately, it appears that D-Link routers implement a protocol which allows router reconfiguration via SOAP and don’t authenticate it properly. Mix in a little DNS rebinding and this likely results in a remote-MitM vulnerability.

The IESG has approved a fix for TLS! The accepted proposal is substantially the same as that proposed by the Sept. 29 meeting of the Project Mogul activity.

Over the coming weeks, the document itself navigates the RFC Editor publication process picking up an RFC number, normative references, and review along the way. But no further technical changes are expected at this point.

Vendors may now deliver to their customers patches which implement the fix blessed by the IETF.

Most vendors have had the details of the fix (with only minor differences) for over three months now. Some are known to have working (and interoperable) implementations internally, so I expect we will see some patches shipping shortly. Since vendors are no longer “blocking on the IETF”, now is when we get to find out which of them are the most responsive when it comes to keeping their customers secure. In all fairness, this has been a rather difficult security problem to address and larger vendors with many products to support have disproportionately more work to do, particularly in the testing process.

One aspect of this fix is that both the client and the server must be patched in order to restore the full security guarantees advertised by TLS. This obviously will not happen tomorrow, but eventually clients and servers will have to start refusing connections with unpatched endpoints (just like they do with ancient versions of SSL today). I.e., their configuration needs to go from “insecure/compatible mode” to “secure/strict mode”. Unfortunately, as long as there is a single unpatched client and a single compatible-mode server in the world (or a compatible-mode client and an unpatched server) there exists a potential vulnerability. Note that some attacks do not require the victim client and server to be expecting to talk the same protocol on the same port!

To this end, in the coming months we will need client applications to begin warning users if they are connecting to an unpatched server. After all, wouldn’t you expect your browser to warn you if your connection could be hijacked because the (supposedly) secure site to which you were connecting was not maintained well enough to apply critical security patches on a regular basis?

In related news:

• IEEE Internet Computing has a nice article on the bug.
• Steve and I will be speaking at Shmoocon 2010 and TROOPERS10 about both the technical aspects of the bug and the some of the meta-disclosure issues we’ve encountered along the way.