It’s somewhat good news – having alternate operating systems encourages competition in the marketplace and makes sure companies innovate.  However, I’m very worried about this news not being a Microsoft/Linux fanbox or a Google hater — there’s just some very disturbing aspects to both this specific product and the potential way Google is heading.

First up, the competition.  The idea it seems behind a “browser based OS” is pretty cool, and certainly applicable to the target market (netbooks) Google is initially aiming at.  Out of the two competitors for running the desktop, I think that Linux is likely to suffer more than Microsoft.  Linux (IMO) is suited to the “try new stuff” people and they will most likely be the early adopters.  There’s certainly going to be some loss in Microsoft’s market share – netbooks is a growing market and Windows 7 is trying to target that.  However, unless netbook manufactures are going to factory install Google’s OS (something that Microsoft is likely to fight hard against happening, and/or unless buyers give the netbook manufactures overwhelming requests for the option), there’s an inertia that has to be overcome.  Everyone knows Windows, how it works, that no matter what you can share with practically everyone else, and the number of tools, utilities, plugins, etc, etc, available – that’s a mightily large incentive you have to displace.  Also, as Google is finding to their benefit right now, even if you have a “better” product, lots of people still won’t switch purely out of habit.

Next, security.  OSes are notoriously difficult to write and to secure.  Google is making the task a little easier by narrowing the focus down (just get one application, the browser, to run and have everything else execute on top of that), but we’ve been seeing browser bugs forever so even that approach isn’t totally effective.  Having an OS that that is a) as homogeneous as a single application to target and b) by definition always connected to the public internet is just a scary target IMO.  I would guess that Google is going to look at using their native code technology, and the fact that Mark Dowd (a God amongst us in the security industry and who’s word carries a lot) has “blessed” the project as secure means a lot, doesn’t spell the end of it – the guys that were part of the security contest looking at the code only had 3 months which sounds like a long time but with any large, complex, codebase time gets eaten up quickly just understanding all the things that it does and how it does them, let alone finding all the edge cases (and this is even considering that the people working on the contest were “full time”, with I highly doubt many, if any at all, were).  So, I believe that unless Google is really careful, and there’s no reason for me to think they wont be, it’s a) going to be a nice target (web+connected to the internet+homogeneous+know problems with web/browser applications) and b) going to take considerable time/effort to get right.

My biggest concern however is the principal behind it.  Writing such an OS (or any major technology for that matter) takes a lot of time and effort.  In a company, that costs “mucho dinero”.  The stated plan is to use Open Source principals/development, but it’s rare that people will do things out of the goodness of their hearts.  So, what are the people developing OSS-fashion are going to get?  Probably the same as Linux dev, but without the distro’s (which people can sometimes make money off) – credibility, bragging rights, skill/experience, etc.  Google, what do they get?  Other than hating Microsoft and going after another of their sacred cows, this is where it gets really scary for me.

Google you see is not a search engine company.  It’s not a software company either.  It’s an advertising company.  That’s how it keeps everything it does free to the consumers by placing ads.  The (considerable) software development and operational costs it takes to bring you search results, GMail, Google Maps, etc, etc, is offset by them bringing in advertising dollars.  Fantastic I say – the fact that they have found an alternate revenue stream, can bring such products to consumers for “free”, and make lots of money themselves is just genius.  However, to make these ads that are pushed out more meaningful and targeted (and therefore ask a higher price to the advertiser because of better conversion rates), Google needs to know a lot about you.  Either through simple stuff like what page you are looking at (context), what you’ve done in the past (history), who you interact with (social graph and shared likes/interests), etc, etc.  The more that is collected, the more ads can be targets, the more valuable those ads become.

Now, I thought Google Voice was scary enough when it was announced a while back.  Being able to track who you are calling, who’s calling you, and the content of the calls is just frightening (yes, I know it’s opt-in but I’m not going down there right now).  However, add the opportunity of tracking your every move while working online in a web-OS, gathering data on likes, dislikes, things you are working on, sites you visit, how often you are on and when/where you buy stuff online – I’m not sure that a company who’s goal is finding out that info could resist seeing some of that data.  Unless it was a non-evil company, which Google obviously is, otherwise they wouldn’t have it on their mission statement. :p

Here’s the problem with that.  Microsoft, Linux, Apple, etc, all produce an operating system but their primary motivation is to sell you that OS and keep you on the platform so that you will buy/use their other products (and sometimes services, but it’s a lot less of a simple tie-in).  A company that makes 90%+ of it’s profits on knowing about it’s users patterns has, I believe, a different motivation.  I’m not saying it’s their sole motivation, or maybe not even a motivation at all (right now), but there’s somewhat a conflict of interests going on.

So, I’m not saying that there’s malicious intentions going on in Google’s collective mind, but there’s certainly another “opportunity” to gather more data here, which is something they love to do.  In the 80’s/90’s Microsoft was known as the evil empire and rumors abounded that they were spying/listening on the users of their software.  I hope that Google doesn’t get the same reputation, although the train is going really fast down those tracks.  The marketplace and security issues are a concern, but the biggest is the privacy and potential interests of being in a totally different revenue stream.  I think Google should silo off this OS to the other “data gathering efforts” they have going come out as well as come up with a work-class “open” privacy policy (and perhaps have 3rd party verification?), and not just warm-and-fuzzy statement of “not evil”, “open source”, and “published privacy policies”, in order to nip any potential of the general public thinking that way in the bud.

The first thing I really like about this post is the introduction where Rich outlines the inherent biases he faces as an analyst, and we all face in one way or the other in our industry.  We have our own “thoughts” on what is going on our there, and what should be going on, but it’s really difficult to get over our own biases and see what is really happening and the thoughts of the people that matter (our clients).  Even talking directly to customers you get skewed in a particular direction, so it’s important to take a wide view, aggregate a lot of data, and try an find the big picture no matter how ugly it might look (and be against your own thoughts/biases).

The main content of the post is going though the how/when/why of clients using web application and data security.  I don’t disagree with much of what Rich has written – why should I as it’s come from clients/customers/people in the field – but I certainly have my own insights that I would like to share.

When it comes to web application and data security, if there isn’t a compliance requirement, there isn’t budget

Foundstone certainly has clients that are like that, but looking out our project sheet, I think it’s probably less than 50% of our work that’s obviously tied to compliance.  That’s not to say that perhaps the client has their own motivation/reason for getting us to review a webapp, do a pen test, etc, but there’s a lot of projects on our books that aren’t simply PCI/HIPPA related.

I would suggest the reason for this is that we’re (Foundstone) aren’t known for simply PCI but more of the “higher-end” work.  There’s a lot of “compliance” in our work in that company X tells company Y that they have to have Foundstone look at their stuff before there’s a deal, but for PCI (and the limited scope it has) there’s cheaper options out there.

PCI is the single biggest compliance driver for web application and data security

In the wider world, I have to agree.  I certainly don’t like it, as most companies exposure to security via PCI simply means network vulnerability scanning and unauthenticated SQL/XSS testing – we all know that’s not even scratching the surface.  I guess the sliver lining, if you really squint, is that at least there’s something making companies look at network/app security, and any long journey starts with the first step.  I believe though that companies are “self-leveling” in that they will always do what in their best interests in keeping going as a company and protecting their business – if security was a big deal (their customers demanded it) and there’s a compelling business reason behind it (not just mandated compliance), every company would be doing it, or at least what works for them.  Darwinian survival really – let the customers and companies choose what’s important for them, but that presupposes that they know what they want/need (MAC vs PC adverts for example).

The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client

and…

WAFs are a quicker hit for PCI compliance

and…

Most WAF deployments are out of band, and false positives are a major problem for default deployments

All add up to a really depressing view for me.  First, the pros and cons of WAFs have been trashed out loads of times, so I’m not going to go into that again.  However, we know that they are not going to find/stop everything (or even a reasonable %age it sounds like from the current state-of-the-art), and the fact that they on an equal footing with security code tools (which being closer to the logic have a much better chance of finding/fixing many more issues than a black-box system) is just wrong IMO.

No surprise that they are being used in PCI compliance though – they are specifically called out as a mitigating control, so an easy choice to make, and are cheep enough to get in lieu of a “real” review, either by a pen-test, code review, or automated scan for that matter.  Also they are a box and something “physical” that people see they are buying for their money.  I’m no accountant, but CAPEX purchases are probably from a different budget and easier to justify (we’ve got something for our money rather than just someone’s time and a pretty report).

The last part though is the most depressing.  Even though WAFs are being used for compliance – more WAFs out there, and a preference to WAFs over security in the code – they are being used out-of-band and suffering from high false-positive rates.  Being out-of-band pretty much means that if they did spot something (forgetting the false-positives at the moment), they can’t do anything about it (directly at least).  If this isn’t shutting the stable door after the horse has already bolted, I’m not sure what is.

Finally, Andre has an interesting point in the comments (although I can’t track it back on one of the main points, so I’m not certain what he was addressing)

The theory that the fault is on the vendors’ ability to set expectations is interesting. However, I think the problem is not that the tools aren’t available and easy to configure, it’s that there are no (ZERO!) people available to run the tools, or that know how to install (let alone run) the tools

My belief is that we’re suffering at the moment that most of the security tools out there are “engineers tools” and not for “general use”.  If you look at most code review or automated scanner tools, to get the most out of them they need quite in-depth configuration and when you get the results often a domain-level expert to interpret them and weed out the false positives and “non issues”.  This makes the experts more efficient, but doesn’t bring the expert-knowledge to the masses (which is what these tools are supposed to do).

The web came to the masses because tools made it easier to create pages (how many people now write HTML directly – I know some of you, myself included, will say “I do!”, but it’s a small population and you really should be spending time on more productive things) and easy to create webapps (PHP and ASP.NET especially really make it simple, not to mention the number of free apps/code there is available ready to download and just use without question).  Until security tools catch up and become that simple, allowing the people writing/developing/deploying these apps to assess the security without having to be an expert with two hats, there’s always going to be a deficiency.

And I guess that’s our problem – we’re running with scissors too fast for our own good.  We’ve not fallen over yet (as an industry – we know companies/people who have but it’s not going to happen to us), and perhaps never will (and if we do, the scissors may miss us or only cause a small cut), but there’s certainly that danger and we should be doing something about it rather than just standing by with the band-aids.

Mom, I’ve just hurt myself!

It looks much prettier than previous versions, and clearly targets enterprise users rather than the “nefarious” uses it can be put to by introducing scheduling, remediation (disabling/locking accounts where the tool managed to crack the password), reporting, etc.  Obviously there’s a multi-use for any security tools, but I hope to see passwords get better especially as the Verizon breach report [pdf] suggested that 40% of intrusions were due to attackers gaining unauthorized access via accounts (or systems/services) that were intended for vendors or remote administration.

I’ve not had a play yet, but will be interested to hear from my colleagues in the field on how well it stands up against their favorites – JTR and Cain.

Welcome back guys – we’ve missed you

http://voices.washingtonpost.com/securityfix/2009/01/payment_processor_breach_may_b.html

The fact that there’s been another breach isn’t all that surprising – we know that security is difficult, the current PCI standard (as much as it’s needed and does at least something) is ineffective at preventing these, and there will always be attack when such data is at stake.  The interesting thing here is that malicious code was living inside the payment processors network for three months by some accounts.

That might sound like a long time, but it’s not really – here’s a graph that I produced for a client (all identifying features removed of course, so no "times/dates", but trust me when I say each tick is a good number of days) showing the propagation of malicious code until they spotted the incident and we helped clear it up (and this graph really shows that one attack/code can easily bring in others).

The larger issues is what data was able to get out, and how.  Many companies forget to do egress filtering and monitoring so not only can this question never be answered, but sometimes they only know they are being attacked when something horrendous happens.

Lessons learnt here I think is that no system is completely impervious to attack – just because you have been reviewed (either PCI or from an external firm) it’s irresponsible to let your guard down on anything.  Egress filtering/logging/monitoring is a must – there’s no data breach if it can’t get out of the network.  Finally, data classification/segregation is really useful as this breach could have been a lot worse (and it still might be – we’re only going on what data the processor said was likely accessed).

First, Obama doesn’t want to give up his blackberry – so here’s a little conjecture of what a presidential one might be like.

http://www.crunchgear.com/2009/01/12/exactly-what-would-a-presidential-mobile-look-like/

Also it seems that as staffers take their new offices they are finding outdated equipment/software, few laptops, and restricted external access.

http://valleywag.gawker.com/5137084/technologys-white-house-of-horrors

To those of us in security (and who have had to work with the government), this is none too surprising.  The name of the game now is security and access control – having laptops (that people can walk away with), external accounts (where data can be dropped), and external access (where "bad things ™" can come in from) is simply a no-no when dealing with sensitive information.  Although Facebook may have been a serious tool during the campaign to reach out to people, now it’s an uncontrolled medium where data (both incoming and outgoing) can be missed – the presidential records act means that any communication from the president or vice-president has to be recorded (and personal accounts can circumvent these – remember the trouble Sarah Palin got into when she had one "work" and one "other" email address [which got hacked into]).  Updates to software/technology in those highly-restricted environments are often very slow because it takes time to determine the impact of such changes.

It looks like some of these issues are already being dragged into the 21st century

http://www.whitehouse.gov/the_press_office/ExecutiveOrderPresidentialRecords/

In no particular order…

Dictionary attacks 101 – From Coding Horror.
Tallying Twitter’s Application Security Best Practice Violations – Zero in  a bit (Veracode’s blog)
A roadmap for the Twitter CSO – Zero Day blog at ZDNet
My Pentest Secret: Password Guessing – Matasano

First up, many of the initial posts I saw claimed the sky was falling.  It seems that 2008 was the year where every single disclosure "broke" the internet.  Well, 2009 is here and everything seems to be working well for me! 

After reading the details about the hack, it’s certainly impressive and a nice demonstration.  Thing is, we’ve known about this specific hack since 2007!  That’s right, this is an actual proof-of-concept for a theoretical attack that was discussed (in some detail – see the researchers paper for links) nearly 2 years ago.  CA’s changed to using SHA1 (we’ve actually known MD5 wasn’t a great hashing algorithm since 2004), and everything was good.

Or perhaps not.  Netcraft’s research shows that 14% of the certs out on the internet use MD5.   I’m not totally sure of this value (and I’m not paying £1200 to see the details of the report) as a cert can be signed with both MD5 and SHA1, but it’s still quite a large percentage.  Seems clear that for some to change, we need an actual exploit rather than just being told something is vulnerable.

The extent of the hack is pretty widespread.  Even though it targeted one CA and their cert creation process, the fact is that once you have a CA cert any other cert can be signed and "trusted" by browsers (even certs that are not chained to that CA, so therefore any site on the net can be forged).  This means that for a man-in-the-middle attack, everything would look good to the end user.  How much is this hack being used?  Well, we have no way of knowing, although it’s doubtful it’s in large circulation by the blackhats – the attack is quite sophisticated, and requires quite a financial commitment.

Microsoft and Mozilla have commented on the issue, and it’s interesting that they talk about EV Certs.  This is all well and good, but I don’t think that this is a mitigation strategy (EV certs have to use SHA1, and therefore are not subject to this hack) – far too often are certs broken for some reason or the other, and users just click through any warnings they get.  Therefore, in a lot of cases, a correctly signed cert, rogue or not, doesn’t even matter!

So, this was seriously interesting research, but rather than the hack itself what is interesting to me is how it’s taken until now for a known, potentially high-risk issue to be addressed.  I guess the "if it’s not broken (well, not too broken at least) don’t fix it" is alive and well

I read a lot of posts before writing this (that I haven’t linked to above), so thanks to the following not only for these specific posts, but for the great work they have been putting in making interesting content to read over the past year.

http://blog.phishme.com/2008/12/more-than-one-way-to-skin-a-ca/
http://www.gnucitizen.org/blog/thoughts-on-the-certificate-authority-attack-presented-at-ccc/
http://securosis.com/2008/12/30/what-average-users-need-to-know-about-the-sslroot-certificate-authority-exploit/
http://spiresecurity.typepad.com/spire_security_viewpoint/2009/01/should-verisign-sue-sotirov-appelbaum.html
http://www.veracode.com/blog/2008/12/major-break-in-md5-signed-x509-certificates/

Have no idea if this is a "new" CSRF version, some regression that made it vulnerable again, or another vector (rumor is XSS rather than CSRF, but no details yet).

…but Google says it isn’t so. Also says that the previous reported domain hijacking(s) weren’t through a CSRF vulnerability.  In the interests of being honest, open, and correct any potential mistakes I make, I’ve updated both the old post, and writing this one.

Now, I’m as skeptical as the next person (ask the people who work with me!), but if they say it’s fixed, and has been for some time, who am I to argue.  The main point I’m trying to make though is despite whatever the vulnerability-de-jour is, webmail is a huge target now that it’s not only just our emails going through it, but effectively our authentication system as well (for lots of places).

With this in mind, we have to make sure that these systems are rock-solid.  There’s no protecting against human stupidity (and I’m stupid as well at times, so that’s not a dig at any user-base inparticular), but it should be really difficult for people to screw up and give attackers access to accounts and their data/info.  There’s far too much to go into the "how" on a stupid blog post like this, and there will be some complaining (both users and programmers) on how to go about this, but I think it’s increasingly becoming obvious that the web just doesn’t have the level of security/quality that it needs to be a "trusted" platform, if that ever can be imagined.

We have such a long way to go.

Nothing new for the people that follow this field, but interesting that the author sees about a 25-30% positive finding rate, and clearly identifies some of the things that the tools miss.

One of the things he mentions just makes me sad though

This is quite annoying in the context that some (thankfully not all) independant commercial testers we have encountered over the years believe an automated test is a sufficient test to charge a fortune for, and rely wholly on.   If we had done with with our internal tests we would have missed several critical “information disclosure” type bugs which were remarkably simple to spot.

These “scan boys” as Curphey used to call them give independent testers/consultants a bad name.  Sure, tools are an important part of any testers arsenal, and are required as a “belt and braces” approach (how stupid would you look if you missed an issue that an automated tool discovered), but simply running a tool and thinking that is sufficient?  What is the client paying for that they wouldn’t get by just running the tool themselves?

Foundstone uses various automated (both web and network) tools at the beginning of a test, mostly for information gathering, discovery, and finding the extremely low-hanging fruit, the rest is performed manually by a well trained, knowledgeable, consultant.  However, even if a tool says it tests for something, part of our methodology is to go back and verify that by hand.  Tools can be wrong after all.

Automated testing tools, especially in the web world, are not at the level where they can be used to find even most of the issues in an application.  Myself and others don’t think it will ever get that far.  For that reason, I don’t think we can “fix” security by “testing it in at the end” – we must build software with the characteristics we want from the beginning, and not patched in from (black-box) test findings.

I actually used this very exploit as an example in my CSRF talk at SDBP, so know that the original version was fixed.  Have no idea if this is a “new” CSRF version, some regression that made it vulnerable again, or another vector (rumor is XSS rather than CSRF, but no details yet).

I’m not all that amazed at the commend in Digg on this – it (still) seems that CSRF is not a very well known attack vector.  One commenter even thinks that turning SSL on makes this go away!  I remember the days when many people thought SSL was the solution to all many webapp vulnerabilities

In any case, I think one of the comments was spot on

GMail could fix this by simply asking you to confirm password when setting a filter that deals with an external email address.

It’s pretty clear by now that technology-only solutions are not keeping up with the attacks.  For things that are as critical as email (and banking), I don’t think users will be all that pissed off if they are asked for their password whenever a sensitive operation is about to take place.  In asking for information that only the legitimate user will know, and can’t be dug out of a page/request, these attacks are effectively mitigated. 

This of course doesn’t help in any way people that choose weak passwords, but that’s another problem.

Updated 11.25.08: 
http://www.mikeandrews.com/2008/11/25/retraction-phishing-not-csrf-leads-to-domain-hijacking/