Rebutting MJR’s rant

It was nice to see Marcus Ranum (who has an interesting slant to the security industry) get some press again. This time it’s on responsible / full / no disclosure. In a probably unrelated attack, his site is defaced by a SEO blackhat. Irony, eh? If only he had patched or used software which has learnt the hard lessons.

Here’s the anti-rant I wrote my co-workers a Friday or two ago:

Ranum’s argument has four major elephant sized flaws (at least).

Firstly, he states that security has not gotten better. This is clearly wrong. Security has gotten a great deal better, but so have the attacks and our knowledge. However, the impact of attacks has been steadily decreasing. When I first joined the Internet, there were perhaps 100,000 people on it at a very small number of sites. That year, the Morris worm nearly destroyed the entire Internet. There have been no significant attacks like that for some time. Yes, there are more attacks, but considering there are more than a billion of us on it now, that’s to be expected. Attacks require a great deal more skill today than in Morris’ time. Old software, particularly in the webappsec is trivial to exploit. Proof – modern stuff which is hardened through the lessons we’ve learnt is very hard to exploit. Software which does not heed the lessons is trivial to exploit (see MJR’s site, natch!). Without some pressure, all software would be trivial to exploit, not just the lesser used stuff.

Secondly, he states that disclosing vulnerabilities is akin to shouting fire when there is barely any smoke. The implication is that you should never shout fire, even if there is the possibility of fire. However, if no one shouted fire, children’s pajamas would still be made of highly flammable materials resulting in third degree burns or death instead of slow or insulating materials we have today. Only through research, standards and indeed, advocates (akin to vulnerability researchers) doing shock stories on tabloid TV did we move from obviously deadly dangerous to moderately safe. Fire is a particularly weak analogy as the metaphor breaks down very quickly – fire always occurs and is a natural phenomena.

Thirdly, Ranum ignores evidence that contradicts his position. Vendors and customers are hurt by rampant full disclosure, and I agree that some folks are only out to get on CNN for a few cycles. However, responsible disclosure is the only proven way to make security sloppy companies like Oracle pay attention – eventually. It made Microsoft more secure, and I think if you look at NT 4.0 (1996) versus Vista (2006), Vista is a much larger but harder target. Oracle’s CSO (is in my view) negligent because she thinks like Ranum, and refused to protect her customers and ipso facto all of us.

Lastly, Ranum HATES – and I mean truly despises – upgrading software. This leads directly to his point of view that if there was no disclosure, there would be no (or much less) patching, therefore he wouldn’t have to upgrade. This is a logical fallacy as one does not lead to the other. If all of us had his world view, we’d be running NCSA web server with no firewall on SunOS 4.1, i.e. completely unsafe. How would have Microsoft|Apple|Sun learnt how to secure (as best they are able) their operating systems without the challenges of security researchers and malware creators? It’s like MSRA golden staph – damn near unkillable around hospitals today. It didn’t get like that because we used soapy water.

He rants against the creation and sale of malware as if we’re powerless to stop it. However, it is already illegal to do this in many countries. So if someone writes malware, they are already breaking the law. Why would they stop now, or in the past in his alternate no disclosure universe.
I remember a few years ago that CERT sat on a major DNS issue for oh 8 years (I’m making this number up, but it was not a few months) until the last root server was upgraded to bind 8.something. There was an architectural flaw that could have destroyed the internet with a few packets. And I knew about this in like 1992 or 1993 and at that stage I was not in the security game fully – just a sysadmin. It only required someone with bad intentions and the Internet would have been dead. Why X years? Because there was no impetus to upgrade the root servers, despite it being 14 times redundant, simply because CERT sat on the problem. When I met Spaf a few years later at a SAGE-AU conference, I asked him about this, and he was unapologetic about it. Who gives him the right to decide if the Internet stays alive or not? It should have been fixed, and indeed it was fixed – eventually.

Will we ever be secure? No. Will Ranum’s or my site be safe from attack? Doubtful. Ranum is simply wrong in his thinking if by stopping disclosure we will suddenly become safe.

Ranum’s alternative is no alternative.

ps. I am no apologist for unrepentant full disclosure types out for their 15 minutes on CNN. Hint: I will never employ or recommend ANY full disclosure folks.

OWASP Top 10 2007 nearly done

This edition’s headings:

A1. Cross-site scripting
A2. Injections
A3. Insecure Remote File Include
A4. Insecure direct object reference
A5. Cross-site request forgeries
A6. Information leakage and improper error handling
A7. Malformed input
A8. Broken authorization
A9. Insecure cryptography and communication
A10. Privilege escalation

Note what’s missing? Note what’s new? ;-)

If you want to review it, please mail me. We are putting it out to at least a month’s peer review, including previous users such as PCI and SANS, as well as folks who had no particular love for the old 2004 edition.

Unlike 2004′s edition, updating the Top 10 will become a yearly event. With some luck, we will be releasing it each and every January.

WebAppSec Past and Future

All the cool kids get the press for the wrong reasons. It’s much easier to destroy than to create. Therefore, my 2006 and 2007 lists will only highlight those things which I think have helped create safer web apps, not made it harder for us to protect against them.

2006 Highlights

  • IE 7.0 released. Seriously. Prevents many phishing attacks, reduces the damage through low privilege browsing, and stops some forms of XSS (including the recent Adobe PDF problem). Firefox and Apple could learn a few things from Microsoft.
  • Publication of Ajax Security guidelines by many folks (including me)
  • PCI updated their guidelines to encourage vendors to take CC handling seriously, mandating code reviews by 2008
  • Folks who are normally hidden started blogging, such as this PCI DSS blog and this
  • OWASP Testing Guide gets off the ground in a big way. When this is released (soon!), normal folks will have a way to review existing code properly.
  • OWASP Autumn of Code starts, funding approximately nine projects (8 were chosen and we funded another as it is strategic to OWASP’s mission). Many projects are nearly finished! This has been extremely successful and we will be doing it again in 2007
  • Encoding gets a fresh look: OWASP Encoding library and Microsoft’s revamped AntiXSS library which takes the refreshing approach of deny all crap and let through known good.

2007 Projections

It’s going to be a very busy year for vendors in this space, such as my new employer, Aspect Security. With PCI compliance coming through the works, folks writing PHP apps finally grokking that they need code reviews and pen tests, it’s going to be a bumper year.

Things that I think will make a difference or need more research:

  • Protections against malicious XSS. This will almost certainly focus attention on Javascript implementations
  • Better browser protections for users. All browsers need to look at IE 7.0 and think of that as a starting point. You hearing me Firefox and Safari / webkit devs?
  • Research into safe I18N methods and prevention. This is an almost completely green field today, and needs serious researchers
  • Working on safer API for free form protocols such as XML and LDAP which are essentially utterly injectable today
  • Work with the PHP group to get them to make PHP 6 safe by default. They have an excellent opportunity and a huge responsibility to not screw up
  • Open source web app sec training for open source languages such as PHP and Ruby is direly needed. Lots of information out there, but how to publish to this audience? Extremely challenging
  • Projects utilizing the latest fads (Spring, Ruby, Ajax, etc) MUST catch up with the latest in webappsec trends or they WILL fail. It is not enough to adopt the latest and greatest fad and think it’s secure. It’s not.
  • Folks like Gunnar Petersen are getting the secure SOA message out there. This baby’s time was several years ago, but I think in 2007 large organizations will finally start realizing that hooking up web services to 30+ year old Cobol is an insane proposition without a dose of security
  • REST will be put to rest, as it is insecure and cannot made to be so… without looking an awful lot like WS-*. At which point you may as well use WS-* and be done with it. SSL != secure.
  • A lot greater focus will have to be paid to business logic security. Code scanners and app scanners CANNOT find this stuff, and yet it is the raison d’etre for the web apps. Securing business logic requires hard graft, and a great deal of focus in the architecture and business requirements phase. Hopefully, OWASP will be working on secure architecture, business requirements and design resources this year.

However, it’s going to be a annus horribulous for folks who cannot or will not undergo PCI compliance. PCI compliance is mandatory in 2008, and doing brain dead stuff like storing credit card details will mean many smaller CC gateways and providers will have to shut down, leaving only the big providers. This will mean higher processing fees and less competition. However, the reality is that the financial and identity theft losses from non-compliant places outweigh the benefits from letting them live. I’m happy to pay a little extra and know that my details are reasonably safe from unsavory types.

It’s not opinion, Richard

For the second time, I helped SANS compile their Top 20. I don’t know about the other sections, C1 is primarily my section. As always, there will be knockers. However, I was a bit surprised about one contrarian, the normally interesting and challenging Richard Bejtlich. Richard writes:


As far as the nature of the list goes, it’s important to realize that it’s based on a bunch of people’s opinions.

Actually, no. My section is based upon hard core data from MITRE, as will the forthcoming OWASP Top 10.

MITRE web app sec data

The only entry which I forced into SANS Top 20 is CSRF because it’s REALLY important to fix over the next 12 months. We only get so many chances to speak to this particular audience and CSRF deserves attention. The OWASP Top 10 also has CSRF. Remote File include, which affects PHP more than most, is EXTREMELY heavily attacked. It’s actually the primary attack vector for PHP stacks. It belongs in the list. My mum can discover XSS – it belongs in there. SQL injection can be found via automated means and this is the worst bit – we have methods to utterly avoid it – if only devs would stop using vulnerable API! rdbms_query() should simply not be supported in future PHP releases. And ditto for other languages and frameworks.

Worse still, Richard misses the forest completely when he says that “… it’s called an ‘attack targets’ document, since there’s nothing inherently ‘vulnerable’ about …”. It doesn’t really matter if it’s a weakness, action item, vulnerability or attack. If it’s something you should know about, it belongs in there. Like phishing, like webappsec, and so on. Don’t play semantics when people are at risk. That’s the job of cigarette and oil companies.

It’s basically impossible to find out how much certain types of attacks net criminals, or how much pain identity theft victims suffer, or how much a life is worth when an attack takes out vulnerable biomedical equipment. I’d rather have my blog spammed by hundreds of scripts than one single skilled and motivated attacker take over the host this blog resides on due to security defects in WP. A simple numerical attack number is useless. A simple $$$ figure is going to be wrong and misleading. It’s impossible to *rate* attacks.

We must do it via vulnerabilities discovered, and I’ve done that.

So for us, MITRE data is as good as it’s going to get, and I’ve used that for the top 4, plus one item which is going to be the major form of weakness/vulnerability/attack as folks work out how horrible it is to use CSRF resistant software, and it’s going to get worse when Ajax enabled apps do *everything* via XHR, rather than just a subset of their functionality.

Rohit did a great job herding many, many cats. I really wanted 10 things in there for developers to check and do as web app sec vulnerabilities are now the Top 11 or so attacks. But SANS is a system administration resource, and thus they turned the focus around for system administrators. Fair enough. That’s why we have links to OWASP for those folks who need it.

For Richard to state that the SANS document is my opinion, I don’t think so. I concentrated heavily on fact. In other related news, the OWASP Top 10 is nearing that happy point when it will need peer reviewing. If you’re interested, come join the Top 10 mail list at OWASP.

ps. that graph above although it is the MITRE data does not indicate the Top 10 headings. We’ve got something special for you all! :)

SANS Top 20

The SANS Top 20 2006 update has been posted.

SANS Top 20 2006

I helped write the C1 Web App Sec section:
C1. Web Applications

We’re working on the updated OWASP Top 10 2007 which interlinks with that. It’s an interesting experience writing something like this for a completely different audience than web developers. As it’s coding issues, the SANS folks wanted things like configuration changes which system administrators could change and improve the security. But that’s not what this section is about.

Hopefully, next year, we can get more focus on the changes organizations who write or buy code can do to improve their security. In the near term, when it’s done, check the OWASP Top 10 2007. It’s very cool and has CSRF in it!

Survey at Casa de Grossman

Jeremiah sent me a survey to fill in. Normally, I don’t like participating in surveys, but this time I made an exception. Jeremiah noted that my responses, although not quite in the boxes he had set out, were still actually pretty useful.

So here are my responses:

1. How many code reviews did you do in 2006?

I do a few but very large code reviews, each involving more than 100,000 lines of code. So although not high in number, the programs process literally billions of dollars in transactions every day. Therefore, extreme care needs to be taken. I am not a automated scanner boy and would be negligent if I only used a tool like PMD or LAPSE to find my findings.

2. What reporting standard do you use?

Jeremiah’s choices here did not include many of the normals, including CWE / CVE from Mitre, OWASP anything (that said, Jeremiah has his own biases to WASC), etc. We also have regulatory regimes on top of webappsec specific lists, which are also not mentioned.

I’m not sure of the validity of this question except to say that it should be the subject of more research.

3. Do you use commercial application scanners during security assessments?

Actually, no.

I use PMD, Find Bugs, and LAPSE, all open source or freebie tools. They are for extreme low lying fruit, and in many cases, like not using “final” or “const” I never report on some of these findings as they have zero security impact.

4. Average number of man-hours required to perform a thorough web application vulnerability assessment on the average commerce website?

This should have been phrased to be PC “Average number of hours per review” as I know some hot chicks and some excellent queens working in our field. :-)

I do > 100 kLoc code bases, I was happy to see that folks are spending more than a week doing code reviews. I dare anyone to do a code review on a system which has > 40 systems it talks to directly, with over 200 seperate value functions and over 100 types of data assets in a week.

Typically, for J2EE, I use the initial kLoc (as reported by sloccount) divide by 1000 to be the number of days and fatten the result by 25%. This works out most of the time. However, a revent Aspect Oriented Programming review using Spring Web Flow blew that estimate out of the water. 5000 lines took 2 weeks. ARGH. It pays to know your technology before you quote on a estimate, particularly if you’re doing fixed price code reviews.

5. Do you recommend Web Application Firewalls?

No.

Unless the organization is a CMM level 5 organization that has nothing else to do and needs a new challenge. Seriously, unless the organization is able to tailor the WAF to the application and keep it up to date, WAFs, particularly appliance (=usually dumb) send the wrong message: that’s there’s a silver $25k bullet to your security problem. This is not the truth and I will not perpetuate it. In addition, such devices nearly always add complexity and add fire to the response | request splitting harm which is real and unavoidable when you add unnecessary devices.

But an organization who sees it as defense in depth control, and is prepared to look after it, and investigate and escalate real problems rather than treat it as a “set and forget” will get a recommendation from me for a serious WAF tool, such as mod_security or similar.

I’ve used mod_security to prevent DDoS against a customer a few years ago, and used properly, WAFs are an invaluable asset. But plonked in and forgotten, they are worse than useless – they give a false sense of security and cost a bucket of money that could have been used for a code review. Most (>90%) organizations in my view are simply not mature enough at IT security to look after them and thus should not use them.

6. What do you think about the updated PCI Data Security Standard v1.1

It’s a good start. However, in the latest edition automated scanner vendors are rubbing their hands with glee. We’re going to have SMEs pay a scanning firm for a clean bill of health (“We do the OWASP Top 10 as the PCI requires” — no you don’t, some of these issues are NP complete problems), and thus will get attacked by a business logic error, or a process error which scanners CANNOT find.

I’m happy to work with PCI to fix up the next edition, but honestly, the most recent release is just better than before.

7. Checking for XSS on public websites without permission?

This is extreme grey area and I lean towards “illegal”.

My personal take is that now that methods are well known to craft really bad JS malware, that poking a public website without authority is just dumb. Don’t do it. If the sites are based upon a public piece of software like UltimaBB or phpBB, sure, go ahead download the software and test offline. That’s what security research is all about. But don’t prod or take out public websites.

In Australia, the computer crimes act and complementary state laws are deliberately vague to allow the book to be thrown at you. If you’re a nuisance, the terms of “unauthorized access” are so vague as to mean you are up a certain creek without a paddle if the owner takes offense. And it’s criminal, not civil trouble you’re in. Police are strapped for cash, and if they think they can obtain publicity and an easy conviction, they will come after you. That gets them more funds and resources if they are successful.
Here’s the actual text. You decide:

Computer trespass.

"9A. A person must not gain access to, or enter, a computer system or part
of a computer system without lawful authority to do so.
Penalty: 25 penalty units or imprisonment for 6 months."

Daniel Cuthbert, an excellent OWASP contributor, was prosecuted and convicted under the much more nebulous UK Computer Misuse Act for having a go at a charity’s website. He now can’t emigrate to Australia, and had difficulty finding work in his chosen industry. Do not try this at home.

http://www.samizdata.net/blog/archives/008118.html

Attack vector for Windows Genuine Disadvantage

The other day, WGA decided that my volume licensed copy of Visio was a pirated copy. This is laughable… and annoying. Luckily, the situation sorted itself out; I have Visio 2007 installed and I was able to use that until Microsoft used the rubber hose on WGA’s servers.

But it got me to thinking how a hostile Trojan could cause massive disruption. Product IDs are easily tamperable. If the user is an administrator, all a Trojan or virus has to do is change the Product ID for Microsoft products (Windows, Office, etc) to random values. It doesn’t need to set it to known pirated Product IDs, but just random ones. These are unlikely to validate under WGA, and millions of folks will end up with software which can open, but not print or save documents. Or in Windows’ case, not boot after 30 days.

Microsoft’s only solution for this would be a massive program of issuing new ProdIDs to legitimate customers at a massive cost to everyone (including Microsoft), or to give up on WGA altogether.

If product IDs are susceptible to change, and they are, they must be better protected by the WGA process. If I’ve thought of this, and I’m not precisely hostile, imagine what the organized crime dudes can do.

MITRE Vulnerability trends released

In September, MITRE talked about statistical proof that apps still suck on a mail list. In fact, web apps suck much more than any other form of vulnerability.

MITRE was surprised that their data set was so popular, and cleaned it up and released it.

http://cwe.mitre.org/documents/vuln-trends.html 

These will form the basis of the OWASP Top 10 2007, and as I’m also working on the SANS Top 20 2006 will contain some or all of this detail, with some luck.

Reviewing Spring Web Flow apps (and JSTL and Spring Framework)

Well, I’ve just had the (somewhat dubious) pleasure of reviewing my first Spring Web Flow app. Initially, I thought ARRRRGH Aspect Oriented Programming (AOP) dudes are on crack

and then

I got the Kool-Aid. Here’s the low down for all you l33t code reviewers: it makes doing code reviews extremely hard … and extremely easy.

About a year and a bit ago, when I was (re-)writing the OWASP Guide, I realized that checklists don’t work. So how do you review code if you’re not looking for say Runtime.exec()? In my day job, technical issues such as cross-site scripting and SQL injections, although embarrasing, are hardly worthwhile compared to the sort of losses that can happen if business logic is wrong.

Sure the checklist approach, particularly OWASP Guide 2.x, produces huge reports, but does it mean anything? In short, no. The value is where the business is. That means understanding what the code does. And along the way, you can have a look at the dangerous stuff, like XSS and SQL injections.
So I started looking at flows more throughly. In normal J2EE programs, this can be a little tricky. In SOA, where apps are strung together dynamically, it seems like it’s impossible.

flows.xml

Start here and then find the sub-flows (often in flows/*.xml). If you know what you’re doing, you can produce a directed graph to understand the flows. This is key to understanding the important flows, and review them early and often.

Once you have decided upon a particular flow, follow it from what I will call the home flow, through to completion.

SWF uses continuations. This is different to many frameworks, but is closer to the way HTTP works in the real world. Tomorrow, we’ll look at what continuations are, and how to exploit them.