The EFF has a whitepaper advocating greater adoption of full disk encryption. The intent is to protect privacy of data during government searches or when a device is stolen. The thing is, while that is a very real risk, it is vastly overshadowed by a far more likely risk for the average user – needing to recover data from an unbootable machine. Given the general prevelence of malware it is highly likely that some form of unbootable recovery will be necessary for the vast majority of users at some point, and while it is possible to recover data from an encrypted drive the majority of solutions require opt-in action in advance to do so (for example, exporting the key to some form of removable media). When 12345 is still a common password in 2011, despite Spaceballs making fun of it decades ago, I think it is highly niave to believe that most users will have taken the appropriate steps in advance to protect themselves when needing to recover an encrypted drive.

So at this point EFF, asking for widespread adoption of encryption when the encryption solutions still aren’t really ready for consumer drive recovery is really asking to generate a much greater and more likely issue than the one you hope to solve. Sadly, such is a thing is all too common in security, where very rarely do solutions come without tradeoffs, but we often don’t consider them. Account lockout is awesome, but denial of service is not. Strong passwords are harder to break, but they are also harder to remember. And so on. One thing security folks have traditionally done a poor job with is weighing the negative effects of their solution versus the positive gains – the EFF is just the latest offender there.

~ Joshbw

Several years ago I worked at Microsoft and during that time I was involved in interviewing several hundred candidates. For those not familiar with the MS interview process (it may have changed) it is broken up into a number of one hour interviews where each interviewer is probing the candidate for specific qualities (not skills – qualities; a person can be taught C# but they can’t easily be taught to work well on a team). My role in the interview was typically to gauge how effective they were at actually engineering a solution – and to be specific here, the focus was not on their proficiency with a particular language; I actually asked for pseudo-code because I didn’t want the candidate caught up in worrying about syntax problems (the IDE/compiler does that for you anyway). What I was looking for was how the candidate made sure they understood the problem, and then what thought they put into designing a solution.

The problem I gave candidates to solve was the following:

• Given a string of arbitrary characters, find every sequence that was a palindrome (a sequence of characters that was the same regardless of being read left->right or right->left)
• Do NOT mark nested palindromes (i.e. one palindrome contained within another). for example aeraweabbadfrar should mark abba and rar, but NOT bb (nested within abba)
• overlapping, but not nested palindromes, should be identified. for example aeraweabbabdf should mark both abba and bab

Within 5 seconds of giving the problem I knew immediately when certain people were going to fail, because they picked up a marker and immediately started writing pseudo code on my whiteboard. They were not going to arrive at anything resembling a working algorithm. For starters, what I provided was an incomplete spec definition. Without getting into implementation specifics (like if this is C/C++ is the string null terminated or is a length param passed), here are some questions that should be asked:

• Should upper and lower case characters be considered equivalent or different?
• Are we talking only about basic Latin alphas? Do numbers count? Do extended Latin characters? Is ô equivalent to ö or are they different? Hell, are we even restricted to Latin chars?
• How should the palindromes be marked? I.e. print to screen, returned in array, written to file, etc?

The point of leaving out some details was to see if the person would just make assumptions, or if they would press me for a full problem definition. Now there is all sorts of psychology at play during an interview that could cause a person to exhibit behavior not indicative of their reaction under normal work conditions, so this alone isn’t a make or break. However asking questions to fully spec out a problem definition was a characteristic behavior of a person who was first really thinking about the problem. The other characteristic behavior was writing out a whole lot of sample inputs, covering a variety of many different input cases, to understand what sort of rules they needed to include in their logic BEFORE they started writing code. Potential variants in input included:

• even vs. odd length string
• even vs. odd length palindromes within string
• no palindromes
• one mega palindrome
• many separated palindromes (i.e. palindromes with non-palindrome characters separating them in the string)
• nested palindromes
• single and multi overlapping palindromes (e.g. cattacat has both cattac and tacat – so only a single overlap. cattacata has cattac, tacat, and ata overlapping in a series)

And so forth. If a person did not at the very least spend a good deal of time brainstorming variants of input before they even started writing a solution, they were guaranteed to arrive at a solution that failed with at least some of the above variants. In my entire time in Redmond, interviewing hundreds of candidates, exactly 3 arrived at a working, pretty much perfect algorithm. A couple more created mostly working algorithms that maybe missed one or two specific variants, or had some simple off by one errors when traversing a string that a couple of minutes at an actual debugger would have found pretty easily – I didn’t hold that against people. The vast, vast majority produced crap, and by in large they were the ones that started trying to white board code immediately.

I don’t know who to attribute the quote to, but I’ve heard it in a number of places: “Crappy programmers spend 90% of their time writing code, 10% of their time thinking; Great programmers do the exact opposite” but it pretty accurately captures the few who did well in the interview and the multitude that did poorly. I also have a different manner of thinking about the same situation – making a distinction between Software Engineering and Software Writing. People who write software largely go about it the same way I go about this blog post – they have some general notion they want to convey, and start typing until they manage to convey it. At the end it isn’t going to be particularly well structured, and could benefit from a whole lot of editing. People who engineer software go about it completely differently – in the extreme, the go about as the folks writing shuttle software go about it. Engineering is a whole lot of time spent fully understanding the problem the code tries to solve, understanding all of the conditions the code will be used in, creating blueprints for the code, documenting everything so that QA and other devs can understand things easily, and only a very little amount of time actually writing code. Engineering is a whole lot of process, and it’s a fair bit of unfun work. That’s why coders by and large prefer to just sit down and write code, and really hate when companies try and dump a bunch of process on them.

A good engineering process pays for itself though. For starters, it’s pointless to write code if it is to solve a problem or serve a function that isn’t well understood. Money is just being thrown away in that scenario (for example, in a past job I shot down a proposal by a dev team to expose error logs to end users to help debug issues when engaging support. For any number of reasons, including security, that isn’t a freaking solution, but more specifically the two real problems that needed to be solved were that enough customers were seeing issues with the product that this feature was proposed in the first place, and that the code wasn’t well instrumented enough to provide support with the error details to address the issue. Giving the customer server error logs doesn’t solve either problem but it does create new ones. I really wish I had the power to fire folks on the spot when they propose stuff like that). On top of that though, ad hoc code tends to be less reusable, more error prone, of lower general quality, less secure, harder to test, offering lower performance, and with a shorter shelf life (because of the proceeding points). You may get initial code faster if the dev just starts writing, but you also get your dinner quicker if the chef doesn’t spend time preparing it. In either case, just because it is faster doesn’t mean it is worth paying for, especially as the speed is an illusion. In the end all of the drawbacks to ad hoc code – the lower quality, increased number of errors, etc. is going to cause the dev to spend much more time revisiting that code rather than working on other things. Test passes are going to take longer. The customer is going to be less happy with the finished product, so the next version is going to revisit things from the past version instead of forging new ground.

So my plea to companies is to really focus on building a great engineering process and then enforcing it. You will produce products faster, your customers will like them more, and for folks like me it makes it a whole lot easier to bake security into development (and thus make your products more secure). It’s a really tall order to get devs to engineer with security in mind when they follow no other engineering process. Its damn easy when devs already have coding standards they follow that just need to be updated for security, when the design process is already very analytical and just needs a slight nudge to include security specific concerns, when QA is already given ample documentation to really test something and can be shown how to include a handful of security tests as well, and so forth. For companies that want to produce secure software the first question they should ask is whether or not they have a culture of software engineering or software writing. If it’s the latter, they have a lot more work ahead of them.

~ Joshbw

The W3C published a draft for a Content Security Policy standard, which I think is generally good news. Hopefully a full standard will get all of the browser vendors on board to finally support it (come on MS – you have otherwise tried to be at the front of the pack for security features; you created HTTP-Only, implemented a reflected xss filter, etc. Why so slow on CSP).

That said, I question how much meaningful impact this will really have, as it is an opt in security feature with fairly high implementation overhead for a lot of sites. It would have been very unpopular, but I think the right thing for the W3C to have done would have been to make same origin CSP the default for all sites declared as an HTML 5 document (<doctype html>), and require the decleration to use HTML 5 specific features. Cross origin scripts, iframe content, etc could still be explicitely enabled via header directive as specified by CSP now, but essentially the site would have to opt out of the most secure configuration rather than opt in as they do now. The incentive for devs to actually code with CSP in mind would be access to HTML 5 features – want to have access to local storage, file system API, video, etc.? Then seperate your script from your markup. (I think the same opt-out approach should be taken with x-frame-options. By default you aren’t frame-able unless you specifically attest that you are).

As mentioned, this would be very unpopular if implemented, at least initially. By five years later it would just be the way things are done, nobody would care, and the change would have done more to blunt XSS than all of the OWASP awareness, dev training, and encoding libraries combined. Buffer overflows haven’t declined because people are better at writing C/C++ – they have declined because more code is written in languages that don’t enable buffer overlows by design (though C# does have the lovely “unsafe” keyword for people hellbent on pointing a gun at their feet). If we want to see the same change for web vulnerabilities we have to similarly change the actual technologies in use to ones that make it difficult for devs to introduce vulnerabilities – starting by mandating rather than suggesting a seperation of markup and script is a step in the right direction.

~ Joshbw

Matt Johansen and Kyle Osborn had a well delivered talk at Blackhat on hacking Google ChromeOS. For those not familiar with ChromeOS it is essentially an OS made up only of the Chome web browser – Google asserts that this creates a malware free operating environment which is not quite accurate as the talk showed. Since ChromeOS lacks any other native app Google has introduced extensions that are what amounts to little weblets with API access to Chrome (Javascript that doesn’t just control the DOM but also the, uh, the chrome/shell of the browser) to provide an app concept that sits between the notion of a native app and a website. The crucial (for this talk) consideration is that these extensions are not sandboxed in the same way that a normal website is – they can create and interact with other tabs, regardless of the domain origins of that tab. Showing what could be done because of this, Matt and Kyle demonstrated that by either subverting a vulnerable plugin (including a google authored scratchpad that has since been fixed) or by putting out a malicious plugin in the extensions market they could essentially compromise any website the user visits (or had visited and still has an active session for). Extensions allow you to inject code into an open tab (and to open tabs and navigate them to a particular page), which means the integrity of any website can be compromised on the client.

What this really means is that malware won’t be barred from ChromeOS – it will simply need to evolve. You will still have trojans, just in the form of malicious extensions hosted in the Chrome Extension market rather than hosted on random websites (and hey, we already seeing closed markets hosting trojans – just see Google’s Android market). It’s still going to have exploitation of installed vulnerable software, just in the form of vulnerable extensions rather than vulnerable apps. That isn’t to say that everything is the direct mirror of the desktop world, but rather simply an illustration that the more permissive you allow running third party code the more malicious actions it can perform (which should be self evident). By being fairly permissive with extensions ChromeOS allows for several exploitation scenarios – they could lock down what extensions do (cutting off API access to tabs for example) but in doing so they also cut down what legitimate extensions are capable of. What the talk really illustrated for Google are lessons that MS is plagued with – no matter how awesome your own security you are still impacted by the permissions you give the third party code a user wants to run, and the security of said third party code.

~ Joshbw

Does anyone know of a decent program that allows you to whitelist which executables may be loaded (even better would be executables, dlls, and assemblies but that would be a bit of a headache to manage)? Conceptually it shouldn’t be that hard to write – just poll the running processes and kill any not in the list as soon as you see them but I don’t really want to take the time to create a whitelist of all of the OS components and services myself (compiling a list of applications I execute is work enough). It seems like a whitelist of executables is way easier to maintain, way less invasive, and potentially much more effective than the signature based virus scanners.

~ Joshbw

It turns out that Green Dam, the censorware that China want’s installed on all machines sold within its borders, is crap. The security researchers who wrote the article in that link found many major vulnerabilities within twelve hours of examining the software. First, it has buffer overlows, which can be exploited just by getting a user to go to a site with a long URL. It captures the URL from the browser and compares it to a black list – the buffer it holds a URL in is apparently fixed length, and less than the maximum length of a URL. Good to know that the developers apparently haven’t learned anything from a decade of widespread C++ exploitation. Also, it’s update mechnism allows arbitrary code execution by design.

The sad thing is that the software itself is pointless. Client software, on a client machine, can be defeated easily by the client. In fact, it has an uninstaller that appears to actually work, so the user doesn’t have to jump through the hoops that most malware would make them. On top of that, if it uses black lists to restrict the habits of would be surfers then its effectiveness is limited. In essance what China has done is mandate that a large number of their users expose their computers to exploitation while not seriously impeding those that want to view objectionable content. All this is going to get them is the ill will of their own citizens.

~ Joshbw

Vipin and Nitin Kumar have apparently released a proof of concept for their Vbootkit 2.0 attack against Win7 based machines. I’ve talke about the attack previously, as it is incorrectly labeled a Windows 7 attack- it is an attack against insecure boot process that then compromises Windows 7. Anyway, their rationale is -

The Kumars are concerned that the attack approach against Windows 7 they have unearthed might be modified by skilled miscreants to develop remote attacks, hence the decision to give white hat security researchers a leg up in developing defences. They also want to make the case to Microsoft that it ought to make improved security features available across all versions of Windows 7, not just the higher-end versions.

Apparently taking issue with the fact that BitLocker is only available on Enterprise and Ultimate versions of Windows. I’m not a huge fan of the tiered versions of Windows, but then again I have an alumni account at the MS company store so I don’t really mind paying $50 for Ultimate. At the same time, I think it is a bit crazy to expect bitlocker to be available for all users- the support costs associated with that idea are pretty high. Regardless, all of that is ignoring that a technical control is not ideal for their attack vector.

What leads to their VBootkit 2.0 being run is physical access to the machine- the ultimate enabler is that they are actually at the hardware. Technical solutions are an inherently poor mitigation to a physical problem. Physical controls are much more appropriate. In data centers simply putting the machine in a sufficiently designed locking server cabinent has neutered this attack, since the attacker would need to first break into the cabinent. For desktop users having a good locking, tamper proof case, the boot sequence set to boot from hard disk first, a BIOS password to protect the boot sequence, and a motherboard that isn’t prone to fail into bios when the keyboard buffer is full will prevent all but the most determined attackers. Physical controls for physical problems, technological controls for technological problems, and so forth.

Most of us are techies and immediately look for some nifty code that solves a problem, but enterprise security is only partially a tech problem. Some times a pad lock is better security than a strong password.

~ Joshbw

Johnny Long has a great auction of stuff available for his I Hack Charities organization. There is some good stuff, and it is a good cause.

- Joshbw

Dear Web Developers,

It’s not kosher to request login information for other websites. Both LinkedIn and Facebook are guilty of asking for your various email credentials so they can harvest your address list under the guise of “making it easier to find your friends” and they are by no means unique in this practice. Doing so does two things- first it makes users accustomed to disclosing credentials to websites unrelated to the site the credentials correspond to. Phishing is a huge issue folks, and we have a hard enough time just getting users to be aware that they really are on their bank website. About the last thing we want is to water down that message and get them accustomed to providing that information on sites they clearly see aren’t the site corresponding to the credentials. Unless you move to two factor authentication the only real way to protect against phishing is user education and training, and this practice completely torpedoes that effort.

The other issue is that you are introducing another link into an already vulnerable chain. Not only does google have to worry about the gmail credentials being properly handled on their site (only sent over SSL, hashed in the database, no sql injection to disclose them, etc), but they now have to worry about how your site secures those credentials (I bet you aren’t hashing the values, since you need to use them outside your system) and they really have no control over it.

So Please, quit asking for credentials to other sites- don’t do what attackers do, otherwise you don’t give people an easy way to distinguish between the two.

~ Joshbw

Jeremiah Grossman asks a series of questions on his blog trying to determine if we disagree with the concept or implementation of WAFs, Certifications, Trust Logos, and Compliance Regulations, so I will indulge the questions.

For WAFs I agree with a certain concept of them. I believe they are bandaids rather than solutions, but that bandaids have their place. The solution is to fix the code and ultimately the robustness of the code is the only real defense for a website. However a problem can be fixed *immediately* with a WAF- a good SDLC would require time for the code to be changed. A root cause of the problem should be analyzed and the application should be inspected for related problems (very likely if the bug got into the code once, it got in more than once). The changes should be thoroughly tested to ensure that functionality is not jeopardized, that the fix works, and that different problems were not introduced. A proper change control process should manage the deployment of the fix. In short, I believe that even if resources can be thrown at the problem immediately, it does not follow that the fix would likewise be immediate. (Tangent- I believe that Firefox is too aggressive on their patch to market strategy and likely takes shortcuts that they shouldn’t. I think it better to fix something right than fast, but I am not certain that Firefox agrees) Web App Firewalls allow an interim fix to put in place between disclosure and a coded solution, and in reality not many organizations can throw immediate resources on the volume of issues that they have. WAFs also offer a bit of defense in depth, which isn’t a bad thing. So long as people focus on that conceptualization of a WAF I think things are fine- my issue is when they are treated as a solution in and of themselves, at which point their limitations will be apparent. A WAF is a generalized appliance, not a specialized solution for a specific site (even with good rules). It doesn’t understand business context and so won’t catch things like unathorized or unintended access.

Professional Certifications I believe serve little point. Their implementations are almost entirely horrible and conceptually there is no certification that says that I will be successful for a given role in a specific organization. They are a decent marketing gimmick to put on a resume to get a bit of attention, and organizations may enjoy advertising how many CISSPs they have to assure clients, but ultimately I will not trust a third party organization in place of my own impressions. When I look at the resume of a candidate I am going to look at what experience is listed to narrow down the folks I want to talk to, and then I am going to probe their knowledge to make sure that it satisfies the needs of my organization. Since that is my inclination when looking for coworkers for my own group, I put absolutely no stock in the number of certifications in outside orgs that I might engage with.

Website Trust Logos are horribly implemented- I can’t think of a single logo peddler whom I believe does a sufficient job of assessing a website (except for PCI Scanless, which is one of the few logos that does *exactly* what it claims to). I will let you in on a little secret though, since I don’t see great harm in it. I have a pair of ADT security placards outside of my home, but no security system installed. If a would be thief is going down my block he is going to see the signs in front of my house, with the possibility of an alarm system backing it up, and opt to hit my neighbor that has no visible security system advertised. It is an entirely deterrent based approach, and while worthless if anyone calls my bluff, the bluff in and of itself is not without utility. I see the various logos as something similar. At the end of the day there is nothing backing them up (and even if they weren’t utterly terrible, in order to make them at all cost effective they aren’t going to be anywhere near as thorough as a proper pen test) but if I have to choose between two otherwise equivalent websites to break into, I am going after the one that didn’t bother to even get the logo. Also, consumers don’t know any better, so it is a cheap way to get them to trust you.

And compliance regulations vary in the effectiveness of the implementations, but I don’t disagree with the concept. My view on regulations in general are that they are a way of mandating certain things that are societaly beneficial, but not necessarily beneficial to the bottom line of a company. As such, left to capitalistic pressures in a vacuum, those things would never happen (or only happen in companies not completely governed by the bottom line). For example, from an economic standpoint it is cheapest for a company to just dump pollutants in a nearby stream rather than properly dispose of them most of the time (depending on the economic power of the locale, and how likely it is for serious legal threats to originate out of the action)- see mountain top removal mining for just such a mentality in action. Thus the government needs to impose regulations to ensure that societal wellbeing is also taken into account. Conceptually I see nothing wrong with the interests of individual entities and the interests of the society being balanced by regulation- that is an optimal solution to natural trends in pure capitalism that allows for most of the efficiency of the system while managing some of the drawbacks.

The flaws arrive in the actual implementation of the regulations. If implemented poorly they can prove to be too much of a burden, overly hard to implement or understand, not fully effective, or as usually the case, all three. PCI is a great example of this- Heartford was a nice and shiney gold partner, following the regulations, and it did absolutely nothing that actually stopped the disclosure of card information. At the same time, the overly specific nature of PCI means it has to be constantly revised, that more secure solutions can technically be non-compliant, and that it is a huge burden to understand and implement the mandates. The whole thing would be much better off if it said that systems and communication channels that deal with card information must have both confidentiality and integrity maintained, followed with recommended baseline guidelines. Rather than check the controls in place, the QSA simply checks to see if they can extract card information. The problem is that PCI is too focused on checklists and not at all focused on what it actually hopes to achieve, so its implementation is pretty worthless.

Regulations only work if they are clear, their restrictions are reasonable, and if they are focused on ensuring *a* solution to the problem, rather than *one* solution to the problem. If I had to choose between my bank information being stored on an encrypted drive in a generally open data center and questionable asset disposal programs, or plain text in a data center with detailed background checks for all employees, strictly enforced physical controls that limit access to the box, and a thorough and consistently applied asset disposal program, I am going to choose the latter because that organization has a clear intent on security, rather than on meeting a checkmark on a list. (ideally I would want the latter with an encrypted drive). I think most security regulations lose focus on this.

~ Joshbw