So I upgraded WP to 2.5 and forgot that I tweaked how some of the Widgets outputted their HTML (it bugs me that I can’t just override the widget functions in my own PHP file, but sadly PHP doesn’t support such functionality).  Thus there is some formatting wonkiness in the standards compliant browsers (looks fine in IE 7 though; render what I mean not what I type) when I upgraded and overwrote my changes.  Fixes will be forthcoming when I have free time, but I am in the process of signing paperwork for a new place to live AND working on several projects at work AND working on several projects outside of work (like modifying phpBB to use prepared statements when the mysqli interface is available and when connecting to mysql > 3.0, since a friend of mine got burned by a retarded MOD that changed input without sanitizing it that in turn allowed for a SQL injection).  Thus free time is an undefined variable at the moment.

~ 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

In the past post I ended up having a discussion with the Opera developer I linked to.  Obviously Opera has some bad blood with MS, but if his complaints are true (namely that MS has been mum about deviations it was planning, despite chairing the HTML 5 WG) I do think he is justified.  I don’t think standards bodies are great at considering security; ultimately most of them tend towards a democratic discussion process, is a nice way of saying the majority get their way.  Security tends to be the minority voice in the tech industry in general, and it seems this holds true among voting members of standards bodies as well, so it follows that as the minority voice it will often be overlooked.

That said, MS has a great deal of influence being the predominant browser manufacturer as well as the chair of that particular WG.  I feel they have the responsibility to disclose when they are going to deviate from the spec for security reasons and clearly articulate their rationale, as they could have huge influence either changing the standard, or getting the other browser manufacturers to follow suite despite the standard.

As an aside, when I get a spare moment this week I’m hoping to get involved in a couple discussions with the WG about concerns I have.  I can’t really complain about security concerns when the WG has an open discussion list for the public to voice issues.

~ Joshbw

Anne van Kesteren has a blog post deriding MS for deviating from the proposed standard with the inclusion of XDomainRequest. Your can read the horribly dry standard as well as the design decisions behind it here.  To be blunt, the standard (as well as Mr. van Kesteren) is wrong and MS is right in this case, though if you have read a previous post of mine it should be evident that I think standards bodies generally suck at including security.  I think the W3C has a habit of focusing on what web developers want to do, and not whether they *should* be able to do it (essentially the same problem MS had pre-SDL; give the users what they want, not what is in their best interest).

Key to the proposed standard, ”cookies and authentication information should be sent in the request”, which is a horrible, horrible idea.  Sure, it allows the inclusion of session specific information, information for a specific user, from an external domain in the web page the user is viewing which could have some interesting mash-up results, but it also allows the website making the request to access to that information.  In response headers, which necessarily need to be queriable from JavaScript to see if the request worked, that cookie information is going to be readable as will the potentially sensitive information returned as content.  There is no good reason why my website should have access to any other website’s cookie info.

One could argue that a website can always deny a request from an external source unless it happens to be from a specific domain (hah, as if that would be spoofed), and essentially grant content only to predetermined trusted callers, but there is already a mechanism for that.  If I have an agreement with Amazon to access their user specific data from my website, I can do so through a webservice call in my server side code.  It does require a bit more work, but that extra work will require both parties to think very carefully about what is exposed and what level of access to give. 

If this is implemented in a browser, it will be exploited.  Large websites with a strong security record will likely implement this functionality securely, but there are a whole lot of companies out there without strong security records, with marketing people calling the shots, who will allow unrestricted third party websites to make calls to their protected content.  The security community will figure out how to steal cookie information using it (with the current proposal, it would be sort of trivial).  The idea that “Cookies and authentication information is already sent cross-site for various HTML elements, such as img, script, and form. This means that such a request does not introduce a new attack vector.” as the design decisions for the W3C proposal states, is hopelessly naive. Citing requests made outside of JavaScript, where the browser returns no significant information to potentially malicious scripts, is very different from making said requests and granting access to the response and content inside of script.  That the standards body can’t grok the difference is quite worrisome.

Microsoft is absolutely correct in their implementation of XDomainRequest.  It should only have access to information that the whole world has access to, and it should not pass any sensitive information (like sessionIDs stored in cookies) that the original domain does not already have access to.  Is it restrictive, absolutely, but for the blackhats as well as the web developers.  That is sort of the point.  There are secure ways to retrieve information from another domain.  It does require more work.  It also requires more work for me to have to verify my identity when using my credit card than it would if everyone would just trust me, but I think we can all agree that is for my own good.

For all of you complaining about MS not supporting the standard with this, please stop considering for a moment what you could do with the W3C proposal, and consider what a malicious person could do.

~ Joshbw

Many, many companies rely on vendors to do some level of development for them.  Even Microsoft, with its 50,000 someodd full time development staff (probably larger now) and equally large number of contingent staff, ends up outsourcing certain development projects to third party companies (in the case of MS, the reason for this is myriad; for one shot projects it makes no sense to form a team that will be disbanded in a couple months.  For established teams, due to the corporate structure, it is actually easier to get millions of dollars more in a budget than a couple more full time employees, so vendor development ends up being a practical way of filling a manpower gap).  For non-software companies vendors play an even larger role.

In my experience with vendor developed code, from a security standpoint it has largely been absolute crap, with few exceptions (just ask the TSA with their recent disclosure fiasco because of a vendor developed website).  The implementation is a mess, and during pentesting the hardest part is documenting all of the myriad of flaws found.  The cause of this seems to be two fold.  First, most vendor companies have no security mindset to speak of and second, the hiring company didn’t make security a requirement during negotiations (though it is sad that security needs to be an explicit requirement but such is the sad state of software development).

To increase the quality of vendor developed code I have a couple practices.  To begin with, anyone interfacing with a vendor should have a degree of expertise in doing so or be accompanied by someone who does.  Having a marketing guy with no product development knowledge to speak of being the sole liaison with a particular vendor is a really bad idea.  You don’t send an accountant to interview potential pilots, so why send a marketing person to interview potential developers?  They are not going to know the correct questions to ask when determining which vendor company to employ.

Speaking of which, one of the correct questions to ask is “Describe your secure engineering practices and policies”.  A vendor that knows anything about security will immediately start citing policy. “At design time we do this, at implementation time this, at test time this” and so forth.  If they hesitate, have very vague or uncertain answers, or just start talking BS, your conversation should be done.  What they mean to say is that they have no secure engineering plan.  As a followup question, assuming they answered positively to the first question, ask them about the security training their developers and testers have.  What percentage have had training, who gave the training, what sort of training was it, how often do they receive followup training?

As fair warning, Vendor companies that can adequately answer such questions are few and far between.  Companies have to search these vendors out, and those vendors rightly charge more than their competitors.  This premium is money saved in the long run.  Insecure implementations by vendors typically need to be heavily modified if not out right discarded to fix the vulnerabilities, and if exploited in the interim often times the cost of the exploit  is many many times the cost of competent engineers.  Choosing a security ignorant vendor will simply lead to needing to hire the competent vendor three months after the project is done (or alternatively hire another security incompetent vendor and repeat ad nauseam until you learn your lesson). 

Security standards need to be part of vendor requirements as much as any other development standards should be (you do have dev standards you give vendors, right?).  The level of security you expect in the finished product is a feature as much as any other functionality that you want the vendor to implement.  The standards should be thorough and often time explicit: stored passwords should be hashed, sensitive data protected, input verified, output sanitized, authorization and authentication requirements should be specific, windows client side apps should enable ASLR and NX (if getting binaries instead of source) for C++ as well as pass prefast, .Net client side apps should pass fxcop, etc.  The vendor’s paycheck should be as contigent on these things as the implementation of any other functionality.

Ideally, you would get the vendor to agree to some sort of maintenance contract, and if so, security issues need to be called out along with every other bug.  In fact, ideally you would make the contract contingent on the vendor being responsible for fixing vulnerabilities regardless of whether there is a maintenance contract in place or not.  Vendor companies pick up secure practices real fast after the execution of such a support clause a couple hundred times, destroying any profit they might make many times over.

If you do these things you will go a long way to improving the security of code you receive from a vendor.  In the end they should be held to standards at least as high as any internal developer.  You are paying through the teeth (or what ever the saying is; I am unclear wear exactly you should pay through) for their time.  It might as well be worth it.

~ Joshbw 

Hey MS, back in the day I used to be able turn javascript off, but IE 7 certainly doesn’t have that feature and I didn’t see it in my look through IE 8.  It would be great if there was a “Paranoid” mode in IE 8, similar to the great NoScript plugin for firefox, that allows me to selectively enable javascript for sites that make heavy use of it (”Paranoid mode” might not be an overly marketable name, so feel free to change the terminology).  You could expand the functionality to granularly block other potentially dangerous functionality, like images and other requests made for offsite resources (in blog comments and forum posts I have seen plenty of XSS attacks based on this), as well as disabling ActiveX controls and other <object> tags on certain websites (considering the number of quicktime/PDF remote exploits I don’t really like the idea of autoloading media in third party players for example).  It would be even better if I could enable this functionality with either a whitelist or blacklist of sites.

In other news, kudos on finally having a decent DOM inspector and javascript debugger!

~ Joshbw

 Update: Yeah, security zones can allow me to do this sort of thing, but it is a pain in the ass.  If I want to lock down my default internet zone to disallow javascript, and then find a website that I want to enable javascript support for, I have to go through tools->internet options->security->sites and add the site to a trusted zone, which isn’t anywhere near as easy as NoScript enabling script for a certain website in FireFox.  It also changes my definition of “trusted site” from one that I trust implicitly with just about any action, including running ActiveX objects unsafe for scripting, to sites I trust to have basic JavaScript support.  I’m not saying Security Zones can’t be modified into something that fulfills this functionality and makes such use practical, but they were not designed for it originally, and would need to be heavily modified with such use in mind.

I’ve only spent an hour or two now with the IE 8 beta, not really enough time to get a real impression of it (there seems to be some nice GUI functionality changes, not much to say on the “standards” compliance yet).  I was happy to see that the new cross domain version of XMLHttpRequest (XDomainRequest) doesn’t send cookies.  When MS first hinted at this feature I was pretty wary.  There is already an XSS method to steal cookies even when HttpOnly is set on the cookie, you essentially make an XMLHttpRequest to the site and read the response headers, but the limitation of this is that you really need to embed this on a web page hosted on the same domain as the source you are making the XMLHttpRequest to (since XMLHttpRequest doesn’t really function all that well across domains).

My concern with cross domain requests was that it would be possible for random attacker Bob (in my world Bob is the generic nefarious individual, much to the consternation of Melinda Gates) to use this same sort of attack, but embedded on completely unrelated webpages.  Cursory examination seems to suggest it won’t be that easy.  There actually seems to be some sort of negotiation necessary just to receive any content.  I’m waiting to see the official MS documentation so I have a better idea what I am doing with the API (more specifically, so I know enough to then try and break the safeguards, because I would rather report a break now and get MS to fix it before they exit beta).  It seems someone else has the same idea, which is good.  I could see a lot of room for abuse if a flaw is found in this scheme so hopefully the security community will do a good job pounding on this functionality before release.

~ Joshbw

UPDATE: for those who want to play around with IE 8 but don’t want to overwrite IE 7 (or 6… please upgrade if you are on 6), MS has free virtual PC images available that already include IE 8. Virtual PC 2007 is needed to run them, but it is also available as a free download and completely rocks as a workstation VM.

Following up yesterday’s post about the firewire hack that lets you read memory over firewire, it was noted in the article I linked to that the hack did not yet work in Vista.  I’m guessing that this is because of the copious use of address space randomization by the OS, which would likely make any attempt to modify the windows password code at a fixed address pretty much worthless.  That said, if you knew a particular signature for the code it seems like you could just dump the ram to your external firewire device, scan it for the signature, and then figure out the randomly created offset; however it might be pretty difficult to figure out that signature in RAM in the first place.  This is quite a bit away from my area of expertise, so thoughts from anyone a bit more knowledgeable in this area?

~ Joshbw

There is currently a fluff piece article on hijacking Windows via Firewire floating around.  Essentially the attack allows someone to network via Firewire, directly access the memory, and futz with the windows password logic, effectively bypassing it.  To this I say, well Duh!  I’ve maintained for quite a while that Firewire was inherently insecure.  It by design requires direct memory access, which in this case I think is a very bad idea.  Internally, a myriad of components use DMA to reduce the load on the processor.  Your networking card really doesn’t want to pester the CPU every time a packet arrives, nor does your SCSI controller really want to bother the CPU every time a sector is read.  DMA is a necessity within the computer case, but you inherently need to trust the contents of your case to do their job.

The difference with Firewire is that the component that has DMA is now external to the system.  Unlike ethernet, where the ethernet card has DMA but the external ethernet connections do not, Firewire is designed so that the external devices have DMA, and said devices could be even be another computer.  At the time of Firewire initial adoption Apple shipped it on all of their PowerBooks, so feasibly carrying just a laptop you could sneak into a corporate important person’s office and exploit the DMA of firewire to access their desktop’s memory.  Now there are tiny little x86 systems with an ethernet port, on board flash for storage, firewire and USB ports, and everything else you would need for an attack inside a pocket instead of inside a backpack. Either way, a company insider could feasibly exploit it.

I can see the logic at the time for the design, where CPUs were slow so you can’t take a hit interfacing with them, eSATA wasn’t an option for removable disks, USB 1.0 was slow (and also gave a CPU hit), etc.  The arguments for allowing DMA were plentiful, and security doesn’t seem like a concern during the specification process during those days. (Bluetooth 1.0 or 1.1 anyone?  Heck, even the Bluetooth 2.0 working spec considers security as an afterthought, or how about 802.11 that launched without even WEP)

What bothers me about this article is the level of irresponsible disclosure on the part of Adam Boileau.  He claims to have notified Microsoft two years ago and is releasing his tool now because MS didn’t act.  If this was a critical vulnerability in SQL Server or IE, I wouldn’t have a huge problem with it (I don’t think full disclosure is a great thing, but at the same time, if a company sits on a critical for two years that is also less than ideal), but the problem is that this is essentially a critical vulnerability in a specification.  Asking one vendor to essentially completely break the spec in their implementation (especially a vendor that gets hammered as often as they do for not supporting certain standards and specifications) is naive (how many devices would be broken if the host didn’t allow DMA).  MS can champion changes in Firewire (best of luck, since Apple rules that roost) but they don’t have control over it, and any change is necessarily going to be long and arduous.  Boileau should have approached a multitude of vendors with his proof of concept, from OS manufacturers (MS and Apple) to PC manufacturers (Dell leaving firewire out of all of their business lineup unless specifically added, with a note about security concerns, would catch IEEE attention), instead of dropping a note to MS and expecting that problem to take care of itself.

Apple probably wouldn’t have listened, they don’t really have a presence in corporate America where this attack would be most damaging nor do they exude much concern over security, but PC manufacturers likely would be a bit more receptive(hey, we get to cut out a component and claim it is to make our customers more secure in the same breadth).  Hitting MS alone and expecting them to muscle the rest of the industry into changing is essentially asking them to take an action that in the past has gotten them in a lot of trouble. Even if all parties concerned were committed to change though, it would take time to update the specification with all of the politics involved, and they can’t just drop support for all existing firewire devices on the market now. At best you could change certain default behaviors.

I guess the lesson here is that if you subscribe to the notion that full disclosure is morally justified so long as you have given the company proper notice, make sure the company has any power to realistically change the issue you are complaining about.  Otherwise you are just sort of an ass, taunting them with a vulnerability they don’t control.

~Joshbw