Following the White Rabbit Blog : security

Is Anybody Listening?

RafalLos — Thu, 15 Oct 2009 16:22:00 GMT

Greetings, I am finally back home after an exhausting trip which had me speaking at 2 conferences back-to-back in separate countries and on opposite side of the coast! I did learn some valuable lessons from speaking at these two wildly different conferences thought, so I thought I would share them with you here for your benefit too.

First off, the Information Security conference I attended on Tuesday in Toronto called "SecTor" was brilliantly run and targeted towards Canadian-based information security professionals and wanna-be security professionals. It's OK to say it, there are plenty of people that attend these conferences who are looking to break into the business and want to learn about information security enough to get a grounding of what the industry is about... so they attend these conferences. My talk "When Web 2.0 Attacks" was well-attended and I even had some big names in my audience (thanks to RSnake, Hoff and a few others that wandered in and out) and I think the overall impression was that the stuff I presented was relevant to people's daily lives in Information Security. That's kind of the problem though...

You see, while I ordinarily wouldn't think twice about educating those in my field ... someone that's been doing this for a while longer than I reminded me a while back that this is what we would call "preaching to the choir". Sure, I tend to agree that even within Information Security not enough people understand Web App Sec well enough to build a program and actually reduce any real risks - but those folks have been hearing this talk for years upon years right? At some point I'm bound to hit the law of diminishing returns; and furthermore, people who didn't agree with me 6 months ago aren't likely to agree with me today. Great conference, great mind-share but it's definitely time to reach a broader audience.

That's where the next conference I spoke at comes in. Wednesday morning, at 4:00am Central time (yea, AM) while some of my colleagues were stumbling into their hotel rooms in downtown Toronto I was hopping into a car and being driven to the airport to head out west. My destination was Anaheim, CA where I would speak at StarWest later that day. I'm still not sure how through the delayed flight, sickness, and almost-missed connection I made it out to the West Coast by 2pm, but I did... and Star West was awesome.

StarWest (run by the SQE folks (www.SQE.com) is nicely put together and serves an entirely new audience of people. Here at StarWest (although I did find it strange that we were in the heart of DisneyLand!) the audience was almost entirely composed of software test engineers, managers and those related to the field. This was a completely different set of ears than what I'm used to ... this was a good thing.

The first thing I heard when I put my welcome slide up was "Hey, isn't security supposed to be done by the security people?" Love it. This is exactly the mentality and walls I was there to break down. I think as we went through the hour-long session on "Detective Work for Testers..." I managed to convince a few people in the audience that their jobs were closely tied to mine in Information Security. Maybe, maybe not. The bottom line is that there were many great folks who came up to me and talked afterwards and through the end of the conference about the absolutely missing component in their SDL that was security. I had one lady in the audience (although she fled before I could get more out of her, and had to track her down myself later on the show floor) tell me that her security team is the developers and that because they tell the bosses that they don't have security issues no one ever tests the code. I wish I could recall where she worked, hopefully no place important like a bank or anything ...

The point is - this was the right audience. If you were there and came to my talk, awesome! If you missed it, slides are posted and we can talk about it whenever you have some time.

Do you believe that Information Security and Software Quality testing is one and the same? Do you believe that a quality defect may as well be a security defect? Can you successfully explain the difference between a security and quality bug?

... I'm fairly sure I have my target audience for the next foreseeable future. Listen up quality testers - I'm coming to a conference near you!

Static Code Analysis Failures

Rafal Los — Tue, 06 May 2008 17:32:00 GMT

Static code analysis failures are costing enterprises money and reputation.

White-box security testing is inherently a flawed proposition for many reasons -but it all comes down to a very simple concept:

Machines do not execute source code, they execute machine code (compiled code). --Paul Anderson (GrammaTech)

If you think this through for a minute you realize that there are a few specific reasons why the above statement fundamentally changes the way that people look at white-box testing, and why this is a losing proposition. Let's analyze this in the context of a web application project for a mythical online bank. Consider that the use-case here is that we are dealing with a bank that has an online presence (currently being analyzed) which will be integrated with a series of existing legacy applications, partners, and external 3rd party components. Given this information let's analyze why white-box analysis (or static source-code analysis) is doomed to fail this project with respect to security.

Compiler Optimizers Break Things - Think of it this way, compilers are designed to make machine code from your source code. That compiler's sole purpose (in most cases) is to create machine code that will be optimized, extremely fast-executing, but not necessarily secure. Often times security functions that people build into source code can be removed by compiler optimizers and most often without our knowledge. These actions often undo many of the advanced security features that developers may consciously insert into their code. Consider the following example:

Developer is paranoid about data-persistence in memory space, and wants to be doubly-sure that variables are expired and destroyed
Developer writes a routine whereby the variable will have a null value written to it before the memory is freed
Compiler optimizer sees this as a double-work scenario, and removes the null-value portion and simply opts to free memory
A potential security vulnerability is created with variable persistence in freed memory space

This example ideally demonstrates how a security vulnerability can be inserted in spite of the developer's best efforts to write secure code. Standard static-code analysis tools which are used to "scan code" at the static-file level will fail to catch this vulnerability. Quite simply - static code analysis fails if it is not supplemented with dynamic analysis.

3rd Party Library Integrations - There is another threat to developing and scanning static code in a white-box format. Inevitably, 3rd party libraries are used to complement features or functionality that are not natively provided by the local development effort. After all, no one re-invents the whole wheel everytime - we simply build what we cannot reuse from someone else's work, then use the publicly available libraries from 3rd parties to fill in the functionality and features that have already been written and (hopefully) tested before. White-box testing (or static code analysis) will absolutely fail in finding flaws when it comes to pulling in 3rd party libraries. By the definition of this type of issue, 3rd party libraries rarely provide you the source to be scanned and checked for weaknesses that will affect your application. What you're left with is someone else's code (in machine-compiled format!) which will be interacting with your application. Would you trust that model?
Static Code Analysis Rarely Understands Data-Flow Modeling (Data Tracing) - If you're scanning your application with a source-code-only analysis tool, you're going to not only miss things that will almost certainly come back to haunt you - but you may also be over-working yourself without a real purpose. Consider the following example to illustrate my point. Before I get into that example though, allow me to explain this idea of "data-flow modeling" for those that are not familiar with this idea.Data-flow modeling seeks to understand how data moves through your application, not just how the application code is written. After all, that's the whole pointn of the application, to work with data. Vulnerabilities lie in manipulating data either to or from the end users or the server(s). Data-flow modeling maps out the data in your appliaction from it's instantiation (maybe when the user types it in) to its resting state (maybe when it's finally written to a database, or handed off to another application or service for additional work). That being said let's consider a web application that has 1,000 forms across 100 pages written in the language of your choice, built to be AJAX. While each page does nothing individually to validate user input (the data source) all variables (data) are filtered through a central validation module deep within the application logic. A standard source-code analysis tool (I have evaluated this and can honestly say this is a real use-case but will not mention the tool) will flag on each and every input that is not validated (within the page) as vulnerable to hudreds of vulnerabilities ranging from XSS (Cross-Site Scripting) to SQL Injection and other attack types. What you are left with is a very lengthy report with hundreds of critical and high vulnerabilities that you now obviously must address... unless you do some dynamic analysis on the code and realize that *none* of those theoretical vulnerabilities are exploitable due to the fact that the application filters all data through the central validator/scrubber.

So, there you have it. Static code analysis is inherently doomed to fail. White-box testing of source-only is flawed. The sky is falling, global warming will kill us all. In my next installment of this column, I'll give you what you need to know to avoid failing in your security initiatives at the development step of the SDLC - remember, knowing is half the battle.

Stay tuned!

If this information disturbs you, and you would like to talk about it directly please don't hesitate to email me directly. I am not a sensationalist, and pride myself on presenting practical solutions to real-world problems which are realistically attainable. Thanks for reading.

Security and Compliance - Strange Bedfellows Indeed

Rafal Los — Thu, 01 May 2008 14:24:00 GMT

It's a classic problem of which came first... the chicken or the egg? politics or corruption? security or compliance? While I admit, it's not such a strange thing to see the two groups working together these days... I would like to point of some of the issues that I've come across between these two very important groups in today's enterprises.

The issue of compliance is much like the issue of legal counsel. All large enterprises, and even most small business have someone that's responsible for compliance - occasionally you'll see an entire department dedicated to the daunting task of keeping up with regulations, compliance policies, and the ever-changing landscape of procedural accountability. Oddly enough, there is not a one-to-one relationship between the compliance department and a security department. I've spent a large portion of my IT career in situations just like this and I would like to share some of my understanding with you.

Compliance, while not always a necessity in private businesses, is almost always present in larger, pubilc enterprises. The compliance department is responsible for making sure the business is in-line with self-imposed corporate regulations and policies, industry-consortium regulatory guidance, government oversight and policy even international laws too! It's amazing these groups can even keep this stuff straight, right? What's equally amazing is how often compliance relies on IT Security for guidance and implementation of compliance components. This of course begs the question - would IT Security exist in some organizations if there was no compliance stipulation for such groups? On the flipside of that... in a perfectly secure world where no one is ever malicious - what would be the need for the compliance group? So while it may be a stretch to say that one group cannot function properly without the other (I will concede that they can, albeit poorly) each is heavily dependant on the other for its very existence within a business. This is where I find some strange... interactions.

As I've stated, the security team often carries out part of compliance policy or regulations; or performs audits to ensure that the same regulations are being followed - but I feel like even in these cases the synergies between these groups are under-utilized. I can't count the number of times I've been turned down for an IT Security initiative (which made perfect business sense, by the way - but was simply under-funded) only to push that same initiative through under the guise of a compliance regulation - through the compliance team. In return... the compliance teams I've had the pleasure to work with have repeatedly called upon my security resources to be the "muscle" behind their policies.

As I travel and talk to different groups about Application Security, I am agaff at the number of times that I get an entirely blank stare when I try to explain how leveraging compliance is a sure-fire way to get security initiatives done. Here's my reasoning... see if you disagree...

Compliance is a "necessary evil" which exists to keep the business in good legal and regulatory standing
IT Security exists to keep the balance of risk/reward within the business IT as balanced as possible
IT Security should be looking to enact initiatives which work to support the business

If you take all 3 points above as truth (and I firmly believe they are) then it's a logical next-step to say that IT Security initiatives and Compliance initiatives will greatly overlap. An overlap within two very necessary units of the enterprise will always, without fail, lend more credibility to their efforts and causes. If both the security and compliance teams are pushing the same agenda, it becomes very difficult for a business owner to simply dismiss that agenda as unnecessary or frivolous.

So a lesson-learned here - if you're not already doing this... here are some very simple yet extremely effective (based on personal experience and first-hand accounts) techniques for getting things "done".

Open a regular dialogue with your complaince team. Meet once a quarter, once a month, or once a week as permissable to discuss what you're independently working on
Find overlaps in your goals from a non-technical perspective
Create a joint strategy for compliance and technical implementation of initiatives previously agreed upon
Review business requirements jointly - ensure that both groups understand each other's point-of-view

Given these very simple, and probably obvious, steps - I can virtually guarantee a more successful IT Security goal achievement. You'll work less uphill, you'll "win" more often, and you'll do a much better job not only understanding but supporting your business - that makes everyone happy.

In "cyberspace"... no one can hear your database scream

Rafal Los — Wed, 09 Apr 2008 12:01:00 GMT

It's 2:34am, local time. You're snoring up a storm after a hard day at the office. You've patched all your servers, your lockdown scripts have been verified, and your IDS is humming along perfectly. Oh, and by the way, someone named "R0kk1t" just stole your customer database. A quick check of the "Security Dashboard" when you get in at 8:00am will show everything is green... You have a serious problem.

Sound like anyone you know? This is a serious concern, and the problem is - it's pervasive. It's scarry that 7 out of every 10 people I talk to about Web Application Security don't have any defenses. When I ask what their defenses are they mention things like firewalls, IDSes, and patch policies - all have absolutely nothing to do with (and will do little for) Web Application Security.

Houston - we have a problem. Even if you're trying to build a program geared towards protecting your web apps - how are you going to justify it? Inevitably someone is going to ask you the daunting question - "So, have we been attacked? How many times?" Odds are you're going to have no idea. All hope is *not* lost though... I have some suggestions from years of this happening to me. Here are some tips on building self-defense mechanisms into your web applications - and how to use them as rudimentary alerting triggers...

Kick out the troublemakers - A well-built web application has to know when someone is just being stupid. If your're tracking logged-in users it's even easier. Track the per-user incidence of "bad data" and if it reaches a specific threshold - expire the session and send that user to a page warning them that they've been bad and must re-login. It's basic, and not hard to do - but rarely implemented. Of course, you'll have to figure out those thresholds and what "bad data" is - but at least you have a start here.
Whitelist - In the point above I said you should track "bad data" or bad user-supplied input but how do you know what is good versus bad? Simple, you first have to define what you should expect from the user. An application should, on a per-page and per-input basis, know exactly what input is allowed and what data sets are in play. You can use regular expressions to validate these lists! For example, if you've got a field that expects social security numbers (don't we all) then you can have this simple bit of JavaScript to validate (obviously you'll want to do this on the server side!)

function isValidSSN(value) {
var re = /^([0-6]\d{2}|7[0-6]\d|77[0-2])([ \-]?)(\d{2})\2(\d{4})$/;
if (!re.test(value)) { return false; }
var temp = value;
if (value.indexOf("-") != -1) { temp = (value.split("-")).join(""); }
if (value.indexOf(" ") != -1) { temp = (value.split(" ")).join(""); }
if (temp.substring(0, 3) == "000") { return false; }
if (temp.substring(3, 5) == "00") { return false; }
if (temp.substring(5, 9) == "0000") { return false; }
return true;
}

Log, Log, Log - Your web applications should always have a separate log file for "unexpected input". In fact, where I've had input into the development process I've required there to be at least 2 log files. First log file logs all "unexpected actions" in a web application, the time/date, the logged-in user, the source, user-agent and all other pertinent details of the "unexpected action" whether it be an exception, a crash, or whatever. The second log file is just a dump of all the weird input people submit - some malicious, some not, to better help write regular expressions to filter the garbage.
Fire Alerts - All the things I've mentioned previously are great - but if no one looks at them, or gets an alert when they fire - they're worthless. Make sure you create actionable alerts from with your application framework. Combine all the loggins, white-listing, and self-defense into something that you can understand. Be careful of the information Monster though... if you're not careful in the way you set this up you'll end up with 10,000 emails/hour and won't be any more effective than having nothing. It's a difficult balance but with practice you'll be one step closer.

Well - I hope you find those useful. If you're willing to share, I would love to hear of some other methods that YOU are using in the real-world! Leave them as a comment here, share with the community - remember we're all smarter when we share information.

"Security Vulnerability" != "Defect" ; why?

Rafal Los — Tue, 01 Apr 2008 11:18:00 GMT

It's one of those obvious things. A defect is a defect, right? Whether the airbag is faulty, or the gas cap doesn't hold pressure... a defect is a defect. The strange thing is - it hasn't been that way, and still isn't that way, in most of the IT shops I've been in. Why?

The reason is simple. Historically, security vulnerabilities have been in a class all their own. In an attempt to put some urgency to the matter, security professionals have labeled defects in the security of their projects (in this case I'm talking about web applications) as an entirely different thing than a functional defect. What we didn't realize is that we were actually doing a dis-service to ourselves and the security cause. You may not agree with me right now - but I'll explain this more clearly, and I think you'll be on board with my thought process.

Let's talk about defects, in general and then apply it to the matter at hand. First, let's identify what a defect is... A defect is, in the dictionary sense (cut from dictionary.com):

de·fect [n. dee-fekt, di-fekt; v. di-fekt] Pronunciation Key - Show IPA Pronunciation

–noun

1.	a shortcoming, fault, or imperfection: a defect in an argument; a defect in a machine.

2.	lack or want, esp. of something essential to perfection or completeness; deficiency: a defect in hearing.

OK, easy enough right? So the first meaning is clear; a defect is a shortcoming, fault, or imperfection. It is reasoned that a defect in a web-based application results when functionality X doesn't work as required. Say you have a button, and the functional specification (we'll get back to this gem in a minute) calls for the button to perform some action, A. During the testing phase of the application, before release to production, a tester or tool is utilized to test the functionality of that button, but instead of action A happening, some other action B happens. This is a defect. There is no doubt in anyone's mind that this immediately gets classified as a defect, put into the defect tracking system and sent back to the developer for remediation. The defect is classified as a higher-priority defect if the function happens to be one that is showcased, or important to the overall functionality of the application. Those of you that already use the HP Quality Center tools know exactly what I'm talking about, and know how this process works. Here's the strange twist though - why is quality testing only done with good data? I understand that you want to make sure that the test cases work properly - but why are the testing options limited? The issue at hand here is a very narrow view of defects, and defect testing.

Back in college, I took very basic programming class and had to write a program that was a calculator. It would ask for two inputs of numbers, and then give you an option to perform either an addition, subtraction, multiplication or division of the inputs. Generally, it was assumed that these would be numbers, but what if they weren't numbers? Most of the students in the class, myself included, never thought about ... "What if someone enters a letter or some other unexpected input?" Well, luckily, the professor chose my application, put it up on the screen for the whole class to see, and promptly entered a and b for the two inputs and tried to add them. When my application core dumped, he explained to the class why I had gotten my first F on a project. I learned a very valuable lesson that day - developers must brace their applications for unexpected input. "Why would anyone want to enter something other than numbers?" wasn't a good enough answer to explain why my application failed. Let's apply this lesson I learned back in college to today's application programmers and functional testers.

Here are the reasons why I think security vulnerabilities aren't seen as "defects" in general...

Security professionals have insisted that a vulnerability is its own separate category - While it is true, some security vulnerabilities are a whole new level of "bad" they should be considered just like any other defect in the application for the sake of tracking and remediation. Web platform managers are generally concerned with meeting the demands of their customers and producing code that is defect-free - and it's our own fault that "vulnerabilities" of the security variety have become some ethereal, magical issue for security nerds to worry about. This matter can only be fixed by changing the naming back... a vulnerability is a defect, period. Security vulnerabilities must be explained as "high-criticality defects" to developers, managers and customers otherwise this situation will never change.
Functional specifications rarely, if ever - call for for security validation - Functional specifications aren't written by security professionals, generally. At best, security professionals have a chance to review the functional specification way too late into the process, while the code is being written and readied for production. This is, once again, our own fault most of the time. The answer to this dilemma is a two-pronged attack. We as security professionals must educate those that write functional specifications, and enlighten them to the need for security features. At the same time, we must work hard to have an active input in the writing and release of functional specification documents. These two vectors are critical to getting secure code as an end-product.
Programmers don't typically think about malicious users - While it would be great to think that one day all developers will inherently write secure code because they will have "learned" what security is, and how important it is to the application - the fact is that it's a pipe dream. Developers care about one thing... meeting functional specifications in the least amount of time possible, and moving on to the next project. Developers like to write optimized code that accomplishes the required tasks in as little time as possible. Solving #2 above will also partly solve this problem. In addition, developers must be given the tools (such as static and dynamic code analysis tools as plug-ins to their IDEs) to make their jobs easier. It is not reasonable to expect developers to be security experts in all aspects, so we must arm them with the tools to be experts, without having to do too much extra work or they won't use those tools.

So what have we learned today?

Security vulnerabilities must be re-classified as easily-understandable "functional defects"
Funcitonal specifications must be written to include provisions for security validation
Quality professionals must be given the tools to test for "security defects" in web applications to close the loop in the lifecycle
Developers must be educated and also given the tools to write more secure code with minimal additional effort

-- I welcome your comments!