If you haven’t read the letter, go back an do so [PDF link].  Please.  I’ll wait.  Lots of people don’t get the importance of a complete HTTPS session (not just when logging in) and hopefully this will help.  Cliff Notes version:

1. Once you have logged in, your session (often via a cookie but not always) is your “token” to that account.  Steal it, or inadvertently disclose it (via HTTP), and the person who has that token can effectively become logged in without knowing the credentials or having to going through the authentication process(1).  If you don’t know what that means, look here for an example.
2. On a mixed HTTP/HTTPS session, an attacker can do some funky things that can break the cross-domain protections and then once again it’s game over – you can’t trust the screen you are seeing and the attacker has control over the browser (session token stealing again, malicious code injection, DOM manipulation, browser flaws, etc, etc).
3. You would assume that in most cases even without account takeover or other injection issues that the information going over the wire you don’t want to broadcast to anyone that’s listening.  Many people’s personal lives are run via web-based email setups and it’s been said many times – gaining someone’s webmail account effectively mean you can gain access to lots of other accounts belonging to that person via password reset functionality.  Webmail is the de-facto master password of the net.

So, there’s very good reason to go HTTPS only.  However, there’s downsides to this.   First one is pretty obvious, second one no so much.

1. Performance.  Many companies assume that having everything go over HTTPS will have a huge performance impact.  There’s no doubt that there’s some performance impact, but the major cost is the HTTPS handshake in the browser and server agreeing on a cipher.  Once that is done, modern browsers can cache that agreement and not have to go through it again.  In some cases it makes sense to keep the connection open.  I should really do my own experiments, but it seems the even an old comparison showed very little degradation of performance on old(er) servers/browsers and without SSL concentrators.  A newer paper [PDF link] with lot more detail certainly shows degradation, but only at high throughputs – something certainly Google or a large/popular service would be concerned about.
2. Injections.  Not the kind of injections we don’t want (2), but injecting ads into HTTPS pages is a lot harder.  If it’s being done cross-site you get those horrible popup “mixed content” warning messages, and if it’s “force injected” (which no-one seems to be doing now, but ISP’s had some fun trying it.  With Google’s main revenue being ads, I can see how that might be an issue.

So, first props for Google mentioning it and of all the main providers of web-based apps out there are doing the right thing, even if not by default.  Second, I’m sure that it would have been done already if there wasn’t concerns, and I’m certain that Google (being Google) are crunching the number to see what impact it will have.  I’m not going to hold my breath, but at least it’s “out there” and I hope more people enable SSL by default.

My belief is that we’re relying on the web so much now that we’re going to have to consider encrypted communication to be the default.  Whether that’s VPNs, SSL concentrators, HTTPS-by-default, I’m not sure – it would be really interesting to see some recent stats of a) the amount of HTTP vs HTTPS traffic out there and b) the impact of HTTPS on a well-designed infrastructure setup to handle it.  If anyone has that info please get in touch while I go about looking for it myself and update here if I find anything interesting.  HTTPS/SSL isn’t the great panacea/silver bullet, but as the story goes, it does provide something and from there we can worry about all the other issues in webapps.

(1) There are ways of further protecting the session token if it is disclosed through tying it to an IP address, browser version, etc, etc, but it’s not foolproof.

(2) I still would rather not have ads injected into any of my pages, but understand the model.  I don’t mind paying for services that I use, but it seems I’m in the minority.

Anyway, normal service resuming.

When I saw the challenge – break into some companies web-based email system – I pretty much knew it would all end in tears.  The idea behind this company and their “security” (the challenge was to break into the CEO’s email account, and they provided the username and password “to make things easier”) is that it uses “two-factor” authentication by calling your registered phone number(s) after you authenticate to confirm a code that was sent to you.  It’s closer to side-channel authentication than two-factor, but I’m really splitting hairs here.

Anyway, the thing that we’ve known for a long time is that even with two-factor authentication, there’s still some really effective attacks, one of which looking at an article reporting the end of the contest and some of the hack technique was clearly used – the good old Trojan attack (via XSS it seems – I would class XSS as a Trojan rather than MITM, but that’s me).

When two-factor authentication is in use, why bother trying to break/crack/defeat the authentication – it’s much easier to wait for the user to authenticate (do all the hard work) and then take over from there.  And that’s probably the attack pattern used (and what I would try myself).  If, as the article suggests, StrongWebmail was susceptible to XSS, then all you have to do is get some javascript (or other script/applet/etc) up onto their server, entice the user to that page (or email message), and let the script pull cookies/authentication tokens.  Once you have them, replay them to the app (substituting them for your original ones), and you’re in and able to masquerade as the target user.

There’s a few things that are a little concerning here though. 

First, that a “secure” webmail provider is susceptible to XSS is unforgivable – it’s just such an obvious attack mechanism and should be easily mitigated (well, not easily – there’s lots of places to “hide” script in HTML, but there’s certainly ways to protect against it).  Not everyone has NoScript (although they should), but even if they did I very much doubt it would have helped.  See, if the user had NoScript, they would have likely had the site trusted (they would have been there before, and as it’s not an “unknown” so would have allowed scripts to run as to probably make the site function correctly).  When the XSS code tries to grab the session cookie, NoScript could have got in the way and stopped it from being POST’ed off site, but it could quite as easily been a GET or even better just CSRF’ed an email back to yourself and voila! no “cross-site” and practically all detection techniques would have missed this. 

Secondly, if this was the case (and I’m by no means sure about this, but looking at the site in Paros it seems to correct), having session cookies set to HTTPOnly may not have been a complete mitigation, but may have saved them.

In conclusion, what was clearly a marketing stunt backfired badly.  They deserve to get their ass handed to them because a) having the community do your pentest work for you is kinda shady, especially for marketing purposes and b) this is such and obvious attack it should have come up in a threat model and have been very strongly validated that it had been mitigated against. 

From the CEO of StrongWebMail:

I think if anything this contest will bring attention [that] the major mail providers … really need to take additional steps to secure their email." We all have sensitive info in our inboxes– how secure are you?

Answer: Not very.

EDIT: In the comments of the PCWorld article, it looks like someone else was onto a different strategy by discovering the “two-factor” phone number (via brute force) and spoofing it – a technique that was also likely to work.

If you are working for a product company and testing your own software and “miss” something, then that’s ok – it’s your own (well, your companys) ass, and hopefully there’s enough controls on the process that someone, somewhere, will catch the most glaringly obvious issues.  You fix it, absorb the loss (if any), and make sure you don’t do it again.  When you are being paid to provide that service externally and also companies are relying on you to ensure security (another issue all-together – simply passing on that responsibility is madness IMO) you have to get it right.

I’m surprised it’s taken this long, but a security (PCI) auditor is being sued for giving the thumbs-up to a company that turned out to be (very) vulnerable.

Now, there’s a lot of squirming PR from the PCI council that every company that was breached and just so happened to have compliance were in-face not in compliance at the time of the breach.  However, what, if to really make it simple, I tested a site and later it was hacked through some SQLi and the client said that they hadn’t update the code or anything so I should have found that vuln.  Obviously, all services consultancies have some legalize in their statements of work that cover them for this (if not, there’s a huge hole waiting for you to fall into), as it’s impossible to “prove” anything is “secure”, but what protects that from happening.

At the moment, I think the only things we have are methodologies/checklists (so we know what was looked at and have a “minimum level of inspection”), some “best practices” (that most of the industry seems to agree on, so we should be looking/testing/advising on them), the professionalism of the people doing the work (goes without question), and reputation (which you don’t want to lose – either individually or as a company as your ability to get future employment/work/contract will certainly suffer).

Are there things that we can do to assure that the assurers (auditors, security consultancies) are doing their job right?  Do we have the same worries with accountants, CPA’s, and people that help you with your taxes?

Rich at Securosis (when those guys post, it’s so insightful it often triggers my own thoughts and a post – it’s been quiet for me from them for a while, but they are back on all cylinders now ) has posted some of his thoughts up on how to make the PCI audit process better, but I think looking at the accounting professionals might be a way to go.  After all, aren’t they doing a similar job as we are doing (approving the state of a company and that there’s no “lying” going on), and they have just as much “wiggle-room/fuzziness” (although numbers are numbers, and much easier to quantify and prove than software and computer systems).

I think we’re going to have to go that way at some point, and perhaps more and more security auditors will get sued in the process.  Privately I’ve said quite a few times that the only two things that might shake the security industry on it’s head both being with ‘L’ – Legislation or Litigation – and now we are seeing both.

I’ve always liked the idea of maturity models – it gives organizations an idea of what other places are doing, and a “where they stand” in the industry (one of the things I’m always asked at the end of project is how did the client compared to “others”, so even post-school/university, people still want to know where on “the curve” they sit!).  The thing that I dislike about maturity models are that they encapsulate a set of activities with associated levels and the assumption is that as you do more of the activities the higher up the levels you get and thus the better you are at whatever the model encapsulates.

That’s not always the truth though.  SEI-CMM was always presented in a way that if you don’t do all the activities for a certain level then you were “stuck” there.  i.e. didn’t do all the activities for level one, but most (if not all) of level two – you’re de-facto level one.  One of the papers my research professor back in the UK (the eminent computer scientist Les Hatton ) was a favorite of mine titled Linux and the CMM [PDF link].  In summary, despite Linux being a rather good bit of software engineering (both process and quality) it is firmly rooted in level 1 – apparently not all of the “activities” are necessary to build good software.  The SEI-CMM has been retired now and we’ve moved on from this idea, but in many cases this view of activities –> levels –> “good/bad” remains.

In BSI-MM there are “levels”, but from what I understand of it you don’t necessarily progress up them (although there’s clearly going to be this thought in some organizations), but rather a set of practices/good ideas/activities that are embodied in the software security initiatives for the organizations(9 of them – all really doing something to improve their software security) that were analyzed to make the model.  To really bring this home you have to see the graph at the end of the FAQ – The “average” maturity for each of the sections in the model are all over the place which means that some companies focus more/less on some activities over others.  Actually digging into the full document itself and reading the introduction/prolog really brings it home of how to best use the model, which I hope more people will do than simply browsing the framework online (how about linking to this text before the model Gary?  I think it might help “set the idea” of how to use the SSF better for casual viewers that don’t want to download and read the entire PDF document – maybe I didn’t find the link on the site though Edit: Ok, I found some at the bottom of the FAQ but I still think it’s a little easy to skip over).

The part for me that I really liked was the section that gave the real stats on who does what.  Like all 9 of the companies did these activities (which made them “core” and probably critical – much like the core competencies in Linux development that made it much more than a level 1 maturity).  Seeing the raw count of how many did each activity was interesting as well – the activities that only one organization was observed doing I would guess that some of it is driven by their operating requirements or compliance needs (perhaps breaking this down by vertical as well would show some interesting correlations?).  One big question as well is answered – “How many security people should I have”.  The answer, at least within the 9 organizations that the model is based on, is 1% of the development staff are dedicated to a “software security group”.  I think there’s there’s an important distinction thought in “development staff” vs “operational staff”, and I believe that this model is only looking at the former so bear that in mind before using this stat too directly which I’m sure is going to be quoted in many a under-resourced IT departments.

In all I think this is a great piece of work and a good insight into the software security practices of companies that are really hard to uncover and even worse to get them to share.  Thanks must go to the authors of this – Gary McGraw, Brian Chess and Sammy Mingues – but also to the organizations that opened up their practices and allowed them to be analyzed, reviewed, categorized and shared.  Information really is power, and this kind of knowledge I fell really does help move our little corner of the industry along for everyone involved that wants to get better and take security engineering seriously.

Week of War on WAF’s: Day 1 — Top ten reasons to wait on WAF’s – As it says on the tin, reasons to wait and not deploy a WAF.  I guess, that this is the post that I disagree with the most out of the series because of some of the items on the list, but that’s beside the point – it’s a good place to start the argument.

Week of War on WAF’s: Day 2 — A look at the past – To show that the argument against has been going on for quite some time, a copy of an email from OWASP to the Application Security Consortium (PCI) in 2004 is presented.

Week of War on WAF’s: Day 3 — Language specific – Points out that differences in how languages/frameworks (PHP, Ruby, ASP.NET, etc, etc) parse CGI variables may leave open holes.  For example, if the WAF is written in C/C++ and parses URL’s one way, the target script may parse it differently (despite what the RFC says) because of canoncalization issues.

Week of War on WAF’s: Day 4 — Closer to the code – Argues that validation should be closer to the code and that there are methods that this can easily be added (one way put forward is Aspect Oriented Programming)

Week of War on WAF’s: Day 5 — Final thoughts – Identifies some short-term alternatives to using a WAF without going through a full SDLC.

A really cool article in the NYT a week or so ago detailed some “additions” that an architect did to a client’s apartment in New York without telling them.  I won’t go into detail because it’s a fascinating read and it will spoil the story.  However, just today I saw that JJ Abrams wants to make a movie based on that article.

Is it me, or does Hollywood have no original ideas left in them?  Sure, it’s an interesting story, but as the Gawker post says, it’s been done before.  McG tried to bring one of my favorite TV shows back in the UK over to the US (in what I heard was a a word-for-word remake) without even consulting with the originators/cast – that went so well a fan revolt eventually canceled the show at the pilot.

It’s not even a few people.  Lots of films recently seem to me to be either remakes, bad sequels, or TV shows adapted for the big screen (how the hell is The A-Team getting remade!).

I thought that Hollywood was the land of the creative geniuses?  What has happened to all the interesting, engaging films and TV series (ok, I’m a big fan of BSG, but that is so different and original vs the 1980’s series I’m not lumping it in with all the others).  There’s a lot of talent out there, so why isn’t it being used?  Is it because the studios just don’t want to take the risk(s) any more and just go for the “safe” option with “established” brands? (how did that work out for you Knight Rider?).  All my favorite shows seem to get canceled very quickly, so how is one supposed to “invest” in a program – looks like I’m just going to have to wait for the DVD’s to appear on NetFlix.

Ideas anyone?

XSS silliness

Obama’s website was found to have lots of XSS issues, and just to be non-partisan, Clinton’s also seems to have had some issues as well.

Is anyone really surprised here?  XSS is the most widespread vulnerability on the web, despite it being one of the simplest to mitigate against.  As the guys as Veracode point out, and the guidance from OWASP, it’s not all about input validation (although that’s not a bad thing), but in this case more specifically output encoding.  It would seem that still, programmers, site developers, etc, just aren’t concerned about doing a very simple API call (such as htmlentities or Server.HTMLEncode) or perhaps even better using one of the AntiXSS libraries before writing to the page, which IMO would mitigate probably 90%+ of all attacks.  I’m not sure if this is simply people being uninformed, laziness, or simple risk acceptance, but I would have expected better of them knowing the exposure the site(s) would obviously get.

Mass SQL injection

If it’s not XSS, it seems that that vulnerability du jour is SQL injection.  Recent news has been circulating about a mass SQLi attack on windows-based webservers.  Looking at the attack myself (there’s good examples here and here) it seems that it’s not MSFT specific, but from reports, the script/bots were specifically targeting ASP pages.  Seems reasonable targeting ASP as it’s an old(er) platform and doesn’t have the same level of in-build protection as ASP.NET and is probably "legacy" code that hasn’t been reviewed/fixed for known security issues as much as "new" code would have been.

Michael Howard wrote about the issue on the SDL blog, and once again, this is an issue that is well known and easily protected against – even more so by looking at the exploit (which was to write scripting to the page via SQLi to change any text in the DB that would in all likelihood get output at some point) and doing some output encoding as discussed above – just because the data is coming from the database doesn’t mean it’s "trusted".  So, defense in depth people!  Stored procedures, read only access, output encoding.

This is why I’m a bit jaded – there’s a lot of talk about vulnerabilities we already know lots about, and have simple ways of mitigating.  What’s at issue is, as I’ve already said above, is ignorance, inactivity, or arrogance, and I’m not sure which is worse.  I’ll get onto each of these in the final section of this post

PCI-DSS 6.6

I’ve said for some time that only two things really force companies to do things they don’t want to, security included, both begin with the letter ‘L’ – legislation or litigation.   Legislation usually is associated with a government passing laws down (e.g. HIPPA, SOX, etc) so companies have to be in compliance, whereas companies may do certain activities to defend themselves and try to avoid costly litigation from people suing them if things go wrong.

The PCI-DSS sort of in my mind falls between these two, with legislation from the major credit card companies giving "guidance" of how to protect cardholder data (and with the vendor risking losing their ability to process credit cards if they are out of this "guidance",  or not in "compliance") and legislation (where if there is a breach, a company that is in compliance can claim that they were at least not negligent in their security).  Often the criticism is that PCI doesn’t have any real "teeth" and it’s mostly a CYA activity.  I disagree to some level because at least it’s doing something (and although I’m not a network guy, it seems that from that aspect it’s doing a reasonably good job), however I do agree that from a software perspective it doesn’t go far enough.  That’s why the next version (specifically the section PCI-DSS 6.6) was so eagerly anticipated, not to mention that it is a requirement (in contrast to optional) starting in June.

There’s been lots of comments about this (too numerous to link to all of them, but there’s refs from these main two), including clarification from PCI themselves.  My take?  Nothing really has changed and as ever things are (still) as clear as mud.  It’s still using OWASP top 10 as it’s "secure coding guidelines" (although it’s dropped the "top 10" part), and there’s still general "fuzziness" over how the testing should be conducted.  I’ve banged my head against this for some time, and not going to waste effort on it any more, but Mark Curphey wrote up what he (and I) feel are the main problems some time ago, along with a possible solution if the effort was ever put into it to really design/write it properly.  Even if a such a "risk based" evaluation criteria ever does get completed, I very much doubt it will be ever replace something like PCI – an approach like that costs money, and no-one really want’s to spend much of it (especially now) on anything that doesn’t provide a clear "return".

Automated scanning

That last sentence is really why so many people signing up for "automated scanning" solutions – it’s generally cheaper, repeatable, and easier to "off-load" to some 3rd-party.  I’ll have to be really careful here (as people that both know me, follow the PCI + scanning news, and know who I ultimately work for can appreciate), but I have huge issues with any fully automated system claiming that they comprehensively test security and give you any form of "you are secure" result.  Gary McGraw calls them "Badness-ometers", which is a great term.

The danger of automated scanning today is that some sites are basing their entire security to them and believing the results these tools/services give them.  When the tool/service fails (a vulnerability is discovered that the tool/service hasn’t found), there’s a big circle of blame that starts – the vuln isn’t all that serious/the tool didn’t find it because it was badly configured/it’s not "real world" exploitable/we don’t test for that/out of scope/etc/etc.  What is even more worrying is that many companies just don’t know that many (most in fact) of the real security issues a site might be concerned about can’t be tested in any (current) meaningful way automatically. I say "current", because who knows what advances we might have in the next 5-10 years.  Automated network scanning works to a useful level because what is being scanned is so homogeneous – there are only so many operating system, only so many network devices – so it’s a lot easier to write tests for them.  From my experience though most websites are bespoke, and there are few similarities from one site to the next – writing generic/reusable tests for these are difficult at best.  I’ve a few ideas that would require more research and investigation, but I’ll leave those for another time.

Software security takes effort and few-and-far-between are putting that effort in.  Some simple activity to give "feel good" security may work to a small degree, but it shouldn’t – the buyer and the vendor don’t have equal information on what is being provided.  Any attempt at pointing out these inconsistencies or providing a standardized way for evaluation results in finger pointing to biases, or just plain obstruction.  Sometimes I wish that I were back in academia to actually do some real analysis on this issue and not worry about upsetting anyone or worrying about job security if you say something that isn’t taken favorably.  One shouldn’t be worried about saying that the Emperor has no clothes, and looking to solve the issue (if it is an issues, and it’s necessary), but many of us are. 

Does security really matter?

Watching all these items arrive in my RSS reader has led me to question if security really does matter outside of us that do it for a living – the first two sections of this post show that extremely common and well-known vulnerabilities are still not being addressed, whereas the last two (if I take them at face value from a very high level) are that web security seems to be heading toward becoming a "checklist" process which a "do the easiest" bent and few people are questioning this move.  The "ignorance, inactivity, or arrogance" question that I mentioned above can be "all of the above", but at different times, like the 5 stages of grief.

Please correct me if I’m wrong on any of the above.  The only answer I can possibly come up with is security doesn’t matter until it matters (no surprise there) and it appears that everyone is just waiting for that "silver bullet" to solve all their problems, most of which they don’t know/care/have the time to deal with.  Jeremiah Grossman writes a similar story, and his conclusion seems to be "virtual patching", which stands to reason as his company is pushing scanning + WAF integration.  There’s a good comment feed that goes along with his post that’s worth following. 

This "point and shoot" method concerns me, even if I benefit from it somewhat in my current employment and industry.  However, with the amount of legacy code out there, and the apparent unconcern (as identified above) at "doing the right thing", it really does seem that a paralysis is setting in while we wait for that "silver bullet" instead of incrementally doing better things (I’ve written about silver bullets and magic beans before) – what we appear to be doing is simply putting a band-aid on the problem.

The ModSecurity blog summarized it nicely, but there are some areas of it that I find a bit weird.

First thing that hits me is that SQL injection is listed as the number one attack vector.  This surprises me somewhat, as XSS seems clearly to be where so many vulnerabilities are being found – you just have to step over to the sl.ackers.org forum to see how often.  However, saying that, some companies (who shall remain nameless) don’t rate XSS injections too highly because it mostly targets end-users – often (but not always) no “data” is lost on the server.  This attitude I think just shows disrespect to users because it pushes security (or insecurity) on to them, and could allow them to throw up their hands and say “well you allowed for your account to be compromised” or “hey, you fell for it” (obviously not using those exact words though).

Although it’s only a few quick sentences, there’s an interesting revelation that one third of the attacks were “operational mistakes” where unintentional publishing of information caused either the site to be at risk, or it’s users details being left out there in the open.  Doesn’t sound far-fetched at all – I’ve had one client that had a very sensitive access database left completely open on a public webserver, and didn’t even have the logs any more to at least see if it was ever accessed!

I’ve argued it before, but 15% of the vulnerabilities exploited were previously known.  ‘Nuf said.

Cross-site request forgery is a tiny 2% of the total.  This is one of the big worrying stats to me because either attackers aren’t yet taking advantage of this vector (which most sites are vulnerable to in some way) or the attacks are just going unnoticed (which wouldn’t be to surprising either as the traffic looks so much like “legitimate” use, and if it’s kept small, users probably wouldn’t notice).

Finally, despite lots of efforts of people either talking about secure code/websites, awareness, community projects, improvements in frameworks, technology, etc, it appears that things are getting worse, not better.  I’m not going to steal another graph from the report as I appreciate I’m pushing it with just one – please grab the report for yourself – but there’s clearly an upwards trend.  There could be an bias as maybe reporting is just better/more frequent because the focus is shifting away from traditional software (and unlike tracking patches from established companies, websites can be patched silently), but it feels about right.

Anyway, interesting stuff, and a big “keep up the great work” to the guys at Breach for doing this and everyone over at the Web Application Security Consortium.  Hit up the links for more info and post your own analysis.

Check out the "about" and "contact" pages to the right, for more information, but for now it’s nice to have you visit, and hope you find something interesting.