Ivan Ristić has an excellent blog post about fixing session hijacking. He is absolutely right that the current hack to add state in web applications absolutely sucks. Storing session information in cookies means it will be stolen from some users, either because HTTPOnly wasn’t used and an XSS flaw allowed for a simple query of the cookie, or it was used and an XSS flaw allowed an attacker to query the response from XHR to get the cookie, or because it was tacked on some place it shouldn’t, or a million other web based attacks. Just as likely, a great deal of malware these days actually scans infected machines and harvests cookie data (since both IE and Firefox keep all of it in the clear in predictable locations). Cookies simply are not secure, so it is silly to store secure information there.

I like the idea of adding it to the encrypted transport layer, as it already manages state anyway. I do think there are some challenges there, particularly when it isn’t the web/application server managing SSL but instead a third party appliance, but it would be a much more secure way of tracking state. The DOM has no access to that, malware on the client system would have a much more difficult time getting that data (it could conceivably configure itself as an SSL proxy, but that is a non-trivial task), and whenever session information is being transmitted the connection should be encrypted anyway.

More worrying to me than sessions is the fact that the vast majority of authentication on the internet is a lie. It does not authenticate an individual, as most think, but rather it authenticates two pieces of trivia associated with a particular account. There is absolutely no assurance that a person using a particular userid/password happens to be the account owner, especially when the userid might as well be public data on most websites (it is either visible, or an email address that can be obtained many ways).

For the average, non-paranoid net citizen, there are hundreds of ways that those two pieces of trivia can be disclosed. Most disclose the same two pieces of trivia whenever they register or sign on to a different site. Some sites, like LinkedIn, actually prompt for the trivia to access other sites (yes, give LinkedIn your login to hotmail, gmail, facebook, etc). Phishers, SMSishers, etc all try to trick people into disclosing the trivia. Every company that hosts the trivia can be a source of breech for it. Dozens of applications exist to guess the trivia. It is inherently a weak and fragile mechanism that is ineffective at assuring identity.

Some companies, like PayPal, are concerned enough about this that they hand out rotating tokens. This is good security, for a handful of sites, but between paypal, my bank, and my VPN token for work I think I have reached my limit of tokens I am willing to keep track of. I know RSA is thrilled about the idea of all big websites giving users tokens, but I sure am not.

Microsoft recognizes this. Craig Mundie gave a good talk at RSA this year about enabling end to end trust- how the client can authenticate who the server is and the server can authenticate who the client is. Most people who misunderstood this thought it would be a return of Palladium (which they focus on protecting DRM, rather than in general the protection of system integrity which was actually the point. Yes, it could protect DRM, but it could also make sure something like Windows Update wasn’t compromised. The problem with security is that it can be used to secure things people don’t agree with) and flipped out, or thought it was some nefarious evil Microsoft plot for world domination (seriously, it is a business, not the villain in an bond movie). That’s a shame, because abstracted from Microsoft this is specifically the type of discussion and innovation that needs to be realized. We need a system that isn’t easily compromised that can identify ourselves to other parties, and vice-a-versa. An example of such a system is two way SSL, but that is not something that would be adequate for the usage scenarios of a human end user.

As an industry I think it is important that we shift to a new paradigm of authentication. I think we need to start talking about various models that can actually realize end to end trust. And unlike sessions and roll your own authentication, I think we need to stop using weak hacks and design it right this time.

~ Joshbw

Well, this is pretty much by design, but poses a risk anyway.  The remote connect in Live Mesh is not RDP, it is a glorified VNC, which makes sense considering that the feature should work in more than XP Pro, and Vista Enterprise and Ultimate, the only Windows clients with RDP.  It would be far superior if it was actually RDP though (hey MS, here is an idea, if the system has RDP enabled, use that instead).

RDP has a nifty and well thought out feature.  When I remotely connect to a computer the local session goes to the locked screen and remains there.  That way people near the remote machine do not see what the remote user is doing, and if the machine was already locked remotely connecting does not unlock it.  With the VNC like bastardization this is not the situation.  The remote session is simply sending key and mouse interrupts and getting a screen grab, nothing anywhere near as fancy as what RDP does.  The result is that when someone remotely connects, anyone near the local machine now also have access and can see everything the remote user is doing.  The remote connection opens the local machine up to access.

Microsoft may have weighed the risks of this and gone ahead anyway.  Host machines are likely to be at home, where the user doesn’t necessarily worry about people seeing what is happening, either because no one should be there to begin with or because they trust anyone who conceivably should be.  Users interacting with the local instance would be apparent to a remote user, as all screen activity is mirrored.  And the computer is locked once the user logs off.

People who live with roommates may not be comfortable with this, especially college kids who may not particularly trust their roommates.  Plenty of users will be remotely logged in, but not actually active (for example, out to lunch without terminating the connection, though I haven’t tested for a timeout), so they may not detect local activity, and other such scenarios. 

Honestly, I can’t think of a great fix given the current implementation.  The client/server is very simple in design and probably can’t keep the OS locked locally without OS changes.  As a possible workaround, I would suggest that if the machine supported RDP Microsoft should instead use that for the connection, offering both a superior user experience and a more secure one.  Additionally, I would posit that people using XP Pro, or either Vista version, represent a different customer segment than typical non-RDP machines, and potentially are in environments that should have tighter controls (for example, business machines where the user is trying to circumvent remote access policies through an easier means, on a poorly configured network that allows them to do so).  Ideally these machines would have policies or network controls preventing such easy access, but the ideal world and the real one are rarely one in the same.

I have to wonder how discoverable this VNC like session will be via google dorks.  It is over port 80, and there are already dorks to find VNC machines.

~ Joshbw

Sorry for the hiatus.  I have some posts culminating but I figured I would fire this one off while it still seemed relevant.  There is a lot of coverage about the current CanSecWest contest and the MacBook Air being compromised in two minutes, which has lead me to many different trains of thought.

First, I think the coverage of "Macbook Air Hacked in two minutes" illustrates very little research on the part of the authors, or an intentional aim at a misleading headline for sensationalist purposes, however my reasoning has nothing to do with the fact that a full day went by before the a successful attack (those arguments are really grasping at straws).  The details of the contest rules are posted here. It should be evident from the rules that the contest was broken up into three days, where each day represents a chance to attack a certain target on the computer.  Day one was essentially an attack against the OS and default services/daemons over a network, day two was an attack against default installed applications (web browsers, media players, etc), and day three was against popular non-default installed third party applications (acrobat, flash, etc), with each day representing a perceived easier target and thus less prize money.  If you read the rules there is one other thing that should stand out; they were posted a couple weeks ago. The hack took two minutes from execution to success, which isn’t surprising, but it took a great deal of time prior to the event for the researchers to find the vulnerability, which they did since they were given a heads up. The researcher didn’t find a vulnerability, write an exploit, and launch an attack in two minutes. The point really was to see what zero days would be found in a couple weeks of competitive research.

This is by no means a scientific way to evaluate security.  If you want to know the relative chance of your platform being vulnerable you have to look at trend data over a period of time and extrapolate the likelihood of a zeroday being known at a given moment, plus vendor patch rates, patch success rates (any recalls, history of not patching root cause), and a billion other factors.  It is complicated enough that the industry has not come up with any common metric of how "secure" an application/platform is.  A contest is not the common metric everyone has been looking for.

That said, this is a black eye for Apple, though one I think most researchers were expecting.  Apple has a strong rhetoric (by that I mean FUD) regarding their security relative to their competitor, but the fact of the matter is that when many very bright minds set their will to compromising the three platforms, Apple fell with perceived ease while neither of the competitors did.  This is going to hurt them, though as I said, I don’t think most security folks were surprised.  Apple has been very vocal about being more secure but their entire rationale seems to be that there is little malware available for their platform (which can be attributed properly to many non-security reasons; economics and propagation potential mostly, which is a post that I really need to finish), rather than the effectiveness of their secure development policy (a subject they have said precisely nothing about, which begs the question exactly what policy they do have) or the skill of their security experts (individuals who seem to have no public reputation, as opposed to the many vocal Microsoft security experts beginning with Michael Howard and working down the list).  An argument like that isn’t exactly convincing, especially when vulnerability data contradicts it.

That Apple got a black eye amuses me, I’m not a fan of false smugness, but I don’t even find that noteworthy.  What I do find noteworthy is the amount of misunderstanding on the various technical blogs/news sites in which this story ran.  Reading the likes of ArsTechnica, Slashdot, or to a lesser extent Engadget and Gizmodo, disturbingly few of the commenters have even a basic clue about security (but boy is it easy to spot the Microsoft employees; just look for the comments that have a clue and mention the SDL).  Misunderstanding or flat out false ideas are rampant among essentially the upper crust of the general consumer technology world.  If the more technical of the end users are this off base it paints a very grim landscape for end user security.  Security starts with education, education of both the developers and the end users.  If the end users don’t understand even the basics of what threats they are exposed to they are not going to understand what they need to do to secure themselves.  If someone doesn’t understand that anyone can walk into their house if they don’t secure the front door they aren’t going to know they need a lock.  Worse, if they think a lawn gnome is better security than a lock they are in trouble (unless it is the lawn gnomes from Invader Zim).

From the Mac user populace, at least in general, I don’t find this surprising.  They have been actively encouraged by their OS vendor to ignore security, which I think is a horribly bad idea, that security is not their concern.  However I would have thought that the more advanced Windows users would be more knowledgeable just based off of the hostility their OS faces regularly, and that Linux users would know more just based off of what they need to know to use the OS.  Sadly this doesn’t seem to be the case.  The top three misconceptions (and my rebuttals) among the threads on the subject seem to be as follows:

1. I don’t run as Root - I have user/os role seperation: Essentially the belief that if you need to sudo, go through UAC, etc, then malware is castrated.  This seems incredibly prevalent among Mac users and surprisingly from Linux users as well, and is a profound misunderstanding.  It first assumes that there is no means to escalate privileges through a flaw in the OS or common application running with increased privileges, which history has shown is not the case.  Worse, it assumes malware would need to.  They don’t seem to understand that malware can do anything that the current user can do.  If the current user has read/write/execute permissions to a resource (choose a combination) then so does the malware.  I don’t know of many users even in Linux that insist on running an account where they need to sudo for everything, because that would be tedious as hell.  Malware as a general user can read from any document that user has normal read access to (say, browser cookies, contact lists, personal documents) and even if there are pretty strict outbound firewall rules can probably use an existing application that already has outbound access to send data.  Firefox is quite extensible after all, and the IWebBrowser2 COM object has the same rules as IE (because it is IE).  Don’t get me wrong, I think account separation is a great thing, but it isn’t horribly limiting to malware, especially when they don’t need to hide from virus scanners. (it is also probably pretty easy to socially engineer a user on either Mac or Windows to allow your malware further access by naming its process iTunes anyway).
2. This wasn’t a big deal as it was an application flaw, they couldn’t compromise the OS: It seems many people think that since no one managed to hit the core OS and services on the first day of the competition that this somehow makes the attack against the browser less important.  I would argue that against the end consumer, even if the OS was open to remote code execution, malware authors would find it easier to target web facing applications like the browser, plugins (flash, quicktime, acrobat), email clients, etc.  OS exploits are dangerous when targeting a specific system, or when many systems are in proximity to each other to facilitate their spread.  It is great for intranet attacks, but not so great for internet attacks, in terms of being able to exploit.  I would posit that OS based attacks are primarily a bane of corporations rather than consumers.  Even in the heyday of the worm, when Windows OS security sucked, the worms most successful at propagation went through email, and relied on email client flaws (well, ignoring worms that had multiple attack vectors like Nimbda; obviously multiple means of propagation is beneficial, all other things being equal).
3. Who cares, this was a browser exploit, just don’t go to sketchy websites: There seems to be a huge perception among people that Internet/browser based attacks only come from questionable websites.  Even if this were true I think it ignores the surfing behavior of most users.  If they see a link in a forum or off of digg, or in a blog comment thread that seems interesting they click on it without thinking.  There are very few people who really are paranoid about everywhere they go on the Internet.  Further, it seems most users are utterly unaware that websites they trust can be compromised, either through some application level injection attack (with estimates of 80% of websites having XSS vulnerabilities of some form I think it is safe to say they will eventually view a compromised website) or through a host/network misconfiguration.  Study after study show that a large percentage of malware is hosted on compromised servers.  Social engineering really isn’t necessary to hit someone with a browser exploit; all that is necessary is to compromise a popular site.

I think the lessons to take away from this contest have little to do with the contest itself, but rather the general public’s response to the contest.  Awareness is the most potent tool security professionals can leverage but it seems clear to me that even among the reasonably knowledgeable geeks we have precious little awareness.  These three seemed the most common and egregious misconceptions, but it is hardly an exhaustive list.  I think it is simply a good demonstration of the incredibly minimal amount of progress made in public education and awareness about security. 

~Joshbw