15 posts left…

I’ve talked about this a few times over the years during various presentations but I wanted to document it here as well. It’s a concept that I’ve been wrestling with for 7+ years and I don’t think I’ve made any headway in convincing anyone, beyond a few head nods. Bad security isn’t just bad because it allows you to be exploited. It’s also a long term cost center. But more interestingly, even the most worthless security tools can be proven to “work” if you look at the numbers. Here’s how.

Let’s say hypothetically that you have only two banks in the entire world: banka.com and bankb.com. Let’s say Snakoil salesman goes up to banka.com and convinces banka.com to try their product. Banka.com is thinking that they are seeing increased fraud (as is the whole industry), and they’re willing to try anything for a few months. Worst case they can always get rid of it if it doesn’t do anything. So they implement Snakeoil into their site. The bad guy takes one look at the Snakeoil and shrugs. Is it worth bothering to figure out how banka.com security works and potentially having to modify their code? Nah, why not just focus on bankb.com double up the fraud, and continue doing the exact same thing they were doing before?

Suddenly banka.com is free of fraud. Snakeoil works, they find! They happily let the Snakeoil salesman use them as a use case. So our Snakeoil salesman goes across the street to bankb.com. Bankb.com has seen a two fold increase in fraud over the last few months (all of banka.com’s fraud plus their own), strangely and they’re desperate to do something about it. Snakeoil salesman is happy to show them how much banka.com has decreased their fraud just by buying their shoddy product. Bankb.com is desperate so they say fine and hand over the cash.

Suddenly the bad guy is presented with a problem. He’s got to find a way around this whole Snakeoil software or he’ll be out of business. So he invests a few hours, finds an easy way around it and voila. Back in business. So the bad guy again diversifies his fraud across both banks again. Banka.com sees an increase in fraud back to the old days, which can’t be correlated to anything having to do with the Snakeoil product. Bankb.com sees their fraud drop immediately after having installed the Snakeoil therefore proving that it works twice if you just look at the numbers.

Meanwhile what has happened? Are the users safer? No, and in fact, in some cases it may even make the users less safe (incidentally, we did manage finally stop AcuTrust as the company is completely gone now). Has this stopped the attacker? Only long enough to work around it. What’s the net effect? The two banks are now spending money on a product that does nothing but they are now convinced that it is saving them from huge amounts of fraud. They have the numbers to back it up - although the numbers are only half the story. Now there’s less money to spend on real security measures. Of course, if you look at it from either bank’s perspective the product did save them and they’ll vehemently disagree that the product doesn’t work, but it also created the problem that it solved in the case of bankb.com (double the fraud).

This goes back to the bear in the woods analogy that I personally hate. The story goes that you don’t have to run faster than the bear, you just have to run faster than the guy next to you. While that’s a funny story, that only works if there are two people and you only encounter one bear. In a true ecosystem you have many many people in the same business, and you have many attackers. If you leave your competitor(s) out to dry that may seem good for you in the short term, but in reality you’re feeding your attacker(s). Ultimately you are allowing the attacker ecosystem to thrive by not reducing the total amount of fraud globally. Yes, this means if you really care about fixing your own problem you have to help your competitors. Think about the bear analogy again. If you feed the guy next to you to the bear, now the bear is satiated. That’s great for a while, and you’re safe. But when the bear is hungry again, guess who he’s going after? You’re much better off working together to kill or scare off the bear in that analogy.

Of course if you’re a short-timer CSO who just wants to have a quick win, guess which option you’ll be going for? Jeremiah had a good insight about why better security is rarely implemented and/or sweeping security changes are rare inside big companies. CSOs are typically only around for a few years. They want to go in, make a big win, and get out before anything big breaks or they get hacked into. After a few years they can no longer blame their predecessor either. They have no incentive to make things right, or go for huge wins. Those wins come with too much risk, and they don’t want their name attached to a fiasco. No, they’re better off doing little to nothing, with a few minor wins that they can put on their resume. It’s a little disheartening, but you can probably tell which CSOs are which by how long they’ve stayed put and by the scale of what they’ve accomplished.

Shared by Jeff Williams
If you're relying on automated tools without a skilled human being involved... your sense of security is false. This article describing Hurricane Earl shows a woman putting a pattern of duct tape on the window. Does this duct tape really help?

No, of course not. Duct tape does nothing to stop the glass for shattering, and does almost nothing to stop fragments flying around.

What it does give people is a false sense of security. For whatever reason, they’ve decided not to buy hurricane shutters (even though they live in a hurricane zone) and not board up their windows with plywood. But they can’t just do nothing, so they resort to sympathetic magic like taping up windows. At least they are putting something on their windows.

Such ignorance is not just useless, but in some cases, can be harmful. Some people believe they should leave their windows open a crack during a hurricane, in order to equalize pressure. The opposite is true: this makes it more likely that the hurricane will pop your roof off. The reason is that wind traveling over your roof creates low pressure above, and wind entering your house creates high pressure inside. This lifts your roof off, in precisely the same manner it lifts an airplane wing when flying.

There are obvious analogies with cybersecurity. People do things, like install anti-virus, firewalls, or WEP, because “doing something” makes them feel good. But they haven’t thought through the cause-and-effect whether doing such things actually work. If you're relying on automated tools without a skilled human being involved... your sense of security is false.

•OWASP Vicnum version 1.4 (PHP/Perl) •Mutillidae version 1.3 (PHP) •Damn Vulnerable Web Application version 1.06 (PHP) •Ghost (PHP) •Peruggia version 1.2 (PHP) •OWASP CSRFGuard Test Application version 2.2 (Java) ...

Have you ever heard someone ask “Do we need to fuzz this?”

This question comes up quite a bit in the context of reactive security work.  There are basically two traditional answers:

• Yes.
  When you’re attempting to find variants of something like a memory corruption bug, fuzzing is your best friend.  It’s a no-brainer.
  
  
• No.  Er, wait.  Sure, uh, go for it...
  When you’re attempting to find variants of something that looks more like a design bug, fuzzing might at first seem silly.  The answer becomes less clear after thinking about it a little more.  With 20/20 hindsight you can usually think up a way in which any particular bug might be caught by an automated process.  Would that automated process fit a loose definition of fuzzing?  Possibly.
  
  This intellectual discussion usually doesn’t go very far.  This is because of a general perception that fuzzing for design bugs just isn’t going to deliver the ROI that creative hacking, code analysis, etc. can provide in a given period of time.  But it’s very hard to say that this is true in all cases.  Hence the vague answer above.

Example

Here’s one simple scenario where a technique that could surely be considered fuzzing (and was specifically designed to identify design bugs) did yield a good result.

While testing the Internet Explorer XSS Filter prototype in 2007, SkyLined identified that classic ASP would simply drop invalidly encoded character sequences from HTTP request querystring parameters prior to the HTTP response formation.  This resulted in a situation where our filter could not properly match requests to responses and thus the filter could be bypassed for apps on classic ASP.

The XSS Filter was adapted to account for this situation and test cases were created.

Later we developed a fuzzer capable of slightly modifying test cases before running them.  As you may imagine, it’s not hard for a simple fuzzer to generate various forms of invalidly encoded character sequences.  As it turned out, our fix for the encoding issue missed a corner case that our fuzzer was able to trigger.  We were then able to fix the variant and add a new test case to cover any future regressions.

Thoughts?

Fuzzing for design bugs is not a new idea.  Just in regards to XSS, it was mentioned by Alexander Sotirov in 2008, and of course the sla.ckers are well known for putting this approach into practice.  What is most interesting to me right now is the question of when / how to apply fuzzing style techniques for design bugs in general.  I don’t recall ever having seen a really good answer to this question.

So I would be interested in your thoughts on classes of design defects that are particularly amenable to some form of fuzzing, as well as classes of design defects where fuzzing is just a waste of time.  (Some other questions: What actions must a DOM crawler have to perform in order to be a true fuzzer, and does it even matter if it’s called a fuzzer or not?)

Feel free to hit me up on Twitter or leave a comment on this blog.

dross

I just dig that image out; I made it for the release of the WASC Threat Classification 2.0

Romain03424422661754357103

Interesting:

Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft's software trusts more than 100 private and government institutions.

Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren't tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motors­and a UAE mobile phone company called Etisalat.

In 2005, a company called CyberTrust­which has since been purchased by Verizon­ gave Etisalat, the government-connected mobile company in the UAE, the right to verify that a site is valid. Here's why this is trouble: Since browsers now automatically trust Etisalat to confirm a site's identity, the company has the potential ability to fake a secure connection to any site Etisalat subscribers might visit using a man-in-the-middle scheme.

schneier110888389224464497591299129032743816257806748650429334202339145567035696569821891134531414684058811202585988719661023088031122769238568184481303386143574287416909709248271686049233117432141916310433130107890991197529744308060419678676185941167681046473434407121812046870906543773005650439971478030852

angry tapir writes "Facebook users will soon have a new way of knocking spammers out of legitimate accounts. The social-networking company is rolling out a new security feature that lets users see which computers and devices are logged into their Facebook accounts, and then removing the ones that they don't want to have access."(author unknown)

Shared by Jeff Williams
Or use OWASP CSRFTester which records playback timings on multistep CSRF.

“Cross Site Request Forgery (CSRF) PoC Template (by Javascript)” project page has been updated.

Please visit the project section:

http://soroush.secproject.com/blog/projects/csrf_poc_template/ 

@ScriptName: Cross Site Request Forgery (CSRF) PoC Template 
@Purposes: For any Legal/Ethical Educational Security Researches Only (without any WARRANTY). You can create your own CSRF PoCs by using this template. Author does not accept any responsibility or liability for the use or misuse of this code. 
@Website: http://soroush.secproject.com/blog/projects/csrf_poc_template/ 
@Code: https://code.google.com/p/csrf-poc-template-by-js/
Or use OWASP CSRFTester which records playback timings on multistep CSRF.

Summer in Idaho is treasured all the more since it is all too brief. We had a long, cold spring - my lilacs were two months behind those of friends and family on the east coast - and some flowers that normally do well here never did poke their colorful heads out of the ground.

My personal gardening forays have been mixed: some things I planted from seeds never came up, and others only just bloomed in August, much to my delight. I am trying to create order from chaos - more specifically, I want a lovely oasis of flowers in a rock garden I have admittedly neglected for several years. Nature abhors a vacuum and thus, she made a successful flanking maneuver to colonize flowerbeds with sagebrush and grasses. I am way beyond "yanking and weed killer" and have traded in my trowel for heavier equipment. You need a shovel and a strong back to pull up a sagebrush and as for the grass, I've had to remove the top three inches of soil in many places and move a number of rocks to get at the root system snaking under them.

I never appreciated the expression, "getting at the root of the problem" until I dealt with invasive sagebrush and "grass-zilla." I have no choice but to do it because if I do not eradicate the root system, I will continue to battle these opportunistic biological interlopers one new sprout at a time. Just as, if you do not figure out the - pun intended - root cause of a security vulnerability, but just fix the symptoms, you will later have to clean up the rest of the buggy snippets that are choking your code.

I have had professional experiences that mirror my rock garden. That is, that there are "interloping and invasive" ideas that take hold with unbelievable tenacity to the point it is hard to eradicate them. The sagebrush and grass of the cybersecurity area are what I can only call the (myth of the) evil vendor cabal (var. multae crappycodae) and supply chain risk management (malwarum hysteriensis). Both have taken hold of otherwise rational human beings just like the pods took over people's minds in Invasion of the Body Snatchers.

In the course of my work, I attend a lot of meetings, seminars and the like on software assurance. The good news is that in the last couple of years, most of the vendors who attend these events (think of the big names in software and hardware) are doing pretty much the same sort of mom and secure apple pie things in software development. The bar, I can say pretty confidently, has been raised. This does not mean industry is perfect, nor does it mean that industry is "done" improving security. I would add that all of us know that building better code is good business: good for customers and good for us. It's also important for critical infrastructure. We get it.

However, to go to some of these meetings, you wouldn't think anything had changed. I have recently been astonished at the statements of opinion - without any facts to back them up - about the state of software development and the motives of those of us who do it, and even more disturbed at what I can only describe as outright hostility to industry in particular and capitalism in general. I suspect at least part of the reason for the hostility is the self-selecting nature of some of these meetings. That is, for some assurance-focused groups, vendors only attend meetings sporadically (because it's more productive to spend time improving your product than in talking about it). That leaves the audience dominated by consultants, academics and policy makers. Each group, in its own way, wants to make the problem better and yet each, in its own way, has a vested interest in convincing other stakeholders that they - and only they - can fix the problem. Many of them have never actually built software or hardware or worked in industry - and it shows. Theory often crumbles upon the altar of actual practice.

What I have heard some of these professional theorists say is not only breathtakingly ironic but often more than a little hypocritical: for example, a tenured academic complaining that industry is "not responsive to the market." (See my earlier blog "The Supply Chain Problem") on fixing the often-execrable cybersecurity education in most university programs and the deafening silence I got in response from the universities I sent letters to.) If you are tenured, you do not have to respond to market forces: you can teach the same thing for thirty years whether or not it is what the market needs or wants and whether or not you are any good at it. (What was that again about being nonresponsive to market forces?)

I am also both amused and annoyed at the hordes of third party consultants all providing a Greek chorus of "you can't trust your suppliers - let us vet them for you." Their purpose in the drama of assurance seems to be the following:

• Create fear, uncertainty and doubt (FUD) in the market - "evil, money-grubbing vendors can't be trusted; good, noble consultants are needed to validate security"
• Draft standards - under contract to the government - that create new, expensive third party software and hardware validation schemes
• Become the "validator" of software after your recommendations to the government - the ones you wrote for them - have been accepted

Could there possibly be a clearer definition of "conflict of interest" than the above? Now, I do not blame anyone for trying to create a market - isn't that what capitalism is? - but trying to create a market for your services by demonizing capitalism is hilariously ironic. One wants to know, "quis custodiet ipsos custodes?" (Who watches the watchers, otherwise known as, "why should I trust consultants who, after all, exist to sell more consulting services?")

The antibusiness rhetoric got so bad once that I took advantage of a keynote I was delivering to remark - because I am nothing if not direct - that, contrary to popular belief, there is no actual Evil Vendor Cabal wherein major software and hardware suppliers collude to determine how we can collectively:

• build worse products
• charge more for them and
• put our customers at increased risk of cyberattack.

It doesn't happen. And furthermore, I added, the government likes and has benefited from buying commercial software for many applications since it is feature rich, maintained regularly, generally very configurable, and runs on a lot of operating systems. "How well," I added, "did it work when government tried to build all these systems from scratch?" The answer is, the government does not have the people or the money to do that: they never did. But the same consultants who are creating FUD about commercial software would be happy to build custom software for everything at 20 times the price, whether or not there is a reason to build custom software.

"You are all in business to make a profit!" one person stated accusingly, as if that were a bad thing. "Yes," I said, "and because we are in business to make a profit, it is very much in our interest to build robust, secure software, because it is enormously expensive for us to fix defects - especially security defects - after we ship software, and we'd much rather spend the resources on building new features we can charge for, instead of on old problems we have to fix in many, many places. Furthermore, we run our own businesses on our own software so if there is horrible security, we are the first 'customer' to suffer. And lastly, if you build buggy, crappy software that performs poorly and is expensive to maintain, you will lose customers to competitors, who love to point at your deficiencies if customers have not already found them."

The second and more disturbingly tenacious idea - and I put this in the category of grass since it seemingly will take a lot of grubbing in the dirt to eradicate it - is what is being called "supply chain risk," this year's hot boy band, judging from the amount of screaming, fainting and hysteria that surrounds it. And yet, if "it" is such a big deal, why oh why can't the people writing papers, draft standards and proposed legislation around "it" describe exactly what they are worried about? I have read multiple pieces of legislation and now, a draft NIST standard on "supply chain risk management" and still there is no clear articulation of "what are you worried about?"

I generally have a high degree of regard for the National Institute of Standards and Technology (NIST). In the past, I've even advocated to get them more money for specific projects that I thought would be a very good use of taxpayer money. I am therefore highly disturbed that a draft standard on supply chain risk management, a problem supposedly critical to our national interests, appears to be authored by contractors and not by NIST. Specifically, two out of three people who worked on the draft are consultants, not NIST employees. (Disclaimer: I know both of them professionally and I am not impugning them personally.) There is no way to know whether the NIST employee who is listed on the standard substantially contributed to the draft or merely managed a contract that "outsourced" development of it.

As I noted earlier, there is an inherent problem in having third parties who would directly stand to benefit if a "standard" is implemented participate in drafting it. Human nature being what it is, the temptation to create future business for oneself is insidiously hard to resist. Moreover, it is exceedingly difficult to resist one's own myopias about how to solve a problem and, let's face it, if you are a consultant, every problem looks like the solution is "hire a consultant." It would be exactly the same thing if, say, the federal government asked Oracle to draft a request for proposal that required a ...database. Does anybody think we could possibly be objective? Even if we tried to be open minded, the set of requirements we would come up with would look suspiciously like Oracle, because that's what we are most familiar with.

Some will argue that this is a draft standard, and will go through revisions, so the provenance of the ideas shouldn't matter. However, NIST's core mission is developing standards. If they are not capable of drafting standards themselves then they should either get the resources to do so or not do it at all. Putting it differently, if you can't perform a core mission, why are you in business? If I may be a bit cheeky here, there is a lesson from Good Old Capitalism here: you cannot be in all market segments (otherwise known as "You can't be all things to all people"). It's better to do a few things well than to try to do everything, and end up doing many things badly. I might add, any business that tried to be in too many market segments that they had no actual expertise in would fail - quickly - because the market imposes that discipline on them.

Back to the heart of the hysteria: what, precisely is meant by "supply chain risk?" At the root of all the agitation there appears to be two concerns, both of which are reasonable and legitimate to some degree. They are:

• Counterfeiting
• Malware

Taking the easier one first, "counterfeiting" in this context means "purchasing a piece of hardware FOO or software BAR where the product is not a bona fide FOO or BAR but a knockoff." (Note: this is not the case of buying a "solid gold Rolex" on the street corner for $10 when you know very well this is not a real Rolex - not at that price.) From the acquirer's viewpoint, the concern is that a counterfeit component will not perform as advertised (i.e., might fail at a critical juncture), or won't be supported/repaired/warranted by the manufacturer (since it is a fake product). It could also include a suspicion that instead of GoodFoo you are getting EvilKnockoffFOO, which does something very different - and malicious - from what it's supposed to do. More on that later.

From the manufacturer's standpoint, counterfeiting cuts into your revenue stream since someone is "free riding" on your brand, your advertising, maybe even your technology, and you are not getting paid for your work. Counterfeits may also damage your brand (when FakeFOO croaks under pressure instead of performing like the real product). Counterfeiting is the non-controversial part of supply chain concerns in that pretty much everybody agrees you should get what you pay for, and if you buy BigVendor's product FOO, version 5, you want to know you are actually getting FOO, version 5 (and not fake FOO). Note: I say, "non controversial," but when you have government customers buying products off eBay (deeply discounted) who are shocked - shocked I tell you! - to discover that they have bought fakes, you do want to say, "do you buy F-22s off eBay? No? Then what makes you think you can buy mission critical hardware off eBay? Buy From An Authorized Distributor, fool!"

The second area of supply chain risk hysteria is malware. Specifically, the concern that someone, somewhere will Put Something Bad in code (such as a kill switch which would render the software or hardware inoperable at a critical juncture). Without ever articulating it, the hysteria is typically that An Evil Foreigner - not a Good American Programmer - will Put Something Bad in Code. (Of course, other countries have precisely the same concern, only in their articulation, it is evil Americans who will Put Something Bad In Code.) The "foreign boogeymen" problem is at the heart of the supply chain risk hysteria and has led to the overreach of proposed solutions for it. (For example, the NIST draft wanted acquirers to be notified of changes to personnel involving "maintenance." Does this mean that every time a company hires a new developer to work on old code - and let's face it, almost everybody who works in development for an established company touches old code at some point - they have to send a letter to Uncle Sam with the name of the employee? Can you say "intrusive?")

So here is my take on the reality of the "malware" part of supply chain. It's a long explanation, and I stole it from a paper I did on supply chain issues for a group of legislators. I offer these ideas as points of clarification that I fervently hope will frame this discussion, before someone, in a burst of public service, creates an entirely new expensive, vague, "construct" of policy remedies for an unbounded problem. Back to my gardening analogy, if eradicating the roots of a plant is important and necessary to kill off a biological interloper, it is also true that some plants will not grow in all climates and in all soil no matter what you do: I cannot grow plumeria (outdoors) in Idaho no matter how hard I try and no matter how much I love it. Similarly, some of the proposed "solutions" to supply chain risk are not going to thrive because of a failure to understand what is reasonable and feasible and will "grow" and what absolutely will not. I'll go farther than that - some of the proposed remedies - and much of what is proposed in the draft NIST standard - should be dosed with weed killer.

Constraint 1: In the general case - and certainly for multi-purpose infrastructure and applications software and hardware - there are no COTS products without global development and manufacturing.

Discussion: The explosion in COTS software and hardware of the past 20 years has occurred precisely because companies are able to gain access to global talent by developing products around the world. For example, a development effort may include personnel on a single "virtual team" who work across the United States and in the United Kingdom and India. COTS suppliers also need access to global resources to support their global customers. For example, COTS suppliers often offer 7x24 support in which responsibility for addressing a critical customer service request migrates around the globe, from support center to support center (often referred to as a "follow the sun" model). Furthermore, the more effective and available (that is, 7x24 and global) support is, the more likely problems will be reported and resolved more quickly for the benefit of all customers. Even smaller firms that produce specialized COTS products (e.g., cryptographic or security software) may use global talent to produce it.

Hardware suppliers are typically no longer "soup to nuts" manufacturers. That is, a hardware supplier may use a global supply network in which components - sourced from multiple entities worldwide - are assembled by another entity. Software is loaded onto the finished hardware in yet another manufacturing step. Global manufacturing and assembly helps hardware suppliers focus on production of the elements for which they can best add value and keeps overall manufacturing and distribution costs low. We take it for granted that we can buy serviceable and powerful personal computers for under $1000, but it was not that long ago that the computing power in the average PC was out of reach for all but highly capitalized entities and special purpose applications. Global manufacturing and distribution makes this possible.

In summary, many organizations that would have deployed custom software and hardware in the past have now "bet the farm" on the use of COTS products because they are cheaper, more feature rich, and more supportable than custom software and hardware. As a result, COTS products are being embedded in many systems - or used in many deployment scenarios - that they were not necessarily designed for. Supply chain risk is by no means the only risk of deploying commercial products in non-commercial threat environments.

Constraint 2: It is not possible to prevent someone from putting something in code that is undetectable and potentially malicious, no matter how much you tighten geographic parameters.

Discussion: One of the main expressions of concern over supply chain risk is the "malware boogeyman," most often associated with the fear that a malicious employee with authorized access to code will put a backdoor or malware in code that is eventually sold to a critical infrastructure provider (e.g., financial services, utilities) or a defense or intelligence agency. Such code, it is feared, could enable an adversary to alter (i.e., change) data or exfiltrate data (e.g., remove copies of data surreptitiously) or make use of a planted "kill switch" to prevent the software or hardware from functioning. Typically, the fear is expressed as "a foreigner" could do this. However, it is unclear precisely what "foreigner" is in this context:

• There are many H1B visa holders (and green card holders) who work for companies located in the United States. Are these "foreigners?"


• There are US citizens who live in countries other than the US and work on code there. Are these "foreigners?" That is, is the fear of code corruption based on geography or national origin of the developer?


• There are developers who are naturalized US citizens (or dual passport holders). Are these "foreigners?"

(Ironically, naturalized citizens and H1B visa holders are arguably more "vetted" that native-born Americans.) It is unclear whether the concern is geographic locale, national origin of a developer or overall development practice and the consistency by which it is applied worldwide.

COTS software, particularly infrastructure software (operating systems, databases, middleware) or packaged applications (customer relationship management (CRM), enterprise resource planning (ERP)) typically has multiple millions of lines of code (e.g., the Oracle database has about 70 million lines of code). Also typically, commercial software is in near-constant state of development: there is always a new version under development or old versions undergoing maintenance. While there are automated tools on the market that can scan source code for exploitable security defects (so-called static analysis tools), such tools find only a portion of exploitable defects and these are typically of the "coding error" variety. They do not find most design defects and they would be unlikely to find deliberately introduced backdoors or malware.

Given the size of COTS code bases, the fact they are in a near constant state of flux, and the limits of automated tools, there is no way to absolutely prevent the insertion of bad code that would have unintended consequences and would not be detectable. (As a proof point, a security expert in command and control systems once put "bad code" in a specific 100 lines of code and challenged code reviewers to find it within the specific 100 lines of code. They couldn't. In other words, even if you know where to look, malware can be and often is undetectable.)

Lastly, we are sticking our collective heads in the sand if we think that no American would ever put something deliberately bad in code. Most of the biggest intelligence leaks of the past were perpetrated by cleared American citizens (e.g., Aldrich Ames, Robert Hanssen and the Walker spy ring). But there are other reasons people could Do Bad Things To Code, such as being underpaid and disgruntled about it (why not stick a back door in code and threaten to shut down systems unless someone gives you a pay raise?).

Constraint 3: Commercial assurance is not "high assurance" and the commercial marketplace will not support high assurance software.

Discussion: Note that there are existing, internationally recognized assurance measures such as the Common Criteria (ISO-15408) that validate that software meets specific (stated) threats it was designed to meet. The Common Criteria supports a sliding scale of assurance (i.e., levels 1 through 7) with different levels of software development rigor required at each level: the higher the assurance level, the more development rigor required to substantiate the higher assurance level. Most commercial software can be evaluated up to Evaluation Assurance Level (EAL) 4 (which, under the Common Criteria Recognition Arrangement (CCRA), is also accepted by other countries that subscribe to the Common Criteria). Few commercial entities ask for or require "high assurance" software and few if any government customers ask for it, either.

What is achievable and commercially feasible is for a supplier to have reasonable controls on access to source code during its development cycle and reasonable use of commercial tools and processes that will find routine "bad code" (such as exploitable coding errors that lead to security vulnerabilities). Such a "raise the bar" exercise may have and likely will have a deterrent affect to the extent that it removes the plausible deniability of a malefactor inserting a common coding error that leads to a security exploit. Using automated vulnerability finding tools, in addition to improving code hygiene, makes it harder for someone to deliberately insert a backdoor masquerading as a common coding error because the tools find many such coding errors. Thus, a malefactor may, at least, have to work harder.

That said, and to Constraint 1, the COTS marketplace will not support significantly higher software assurance levels such as manual code review of 70 million lines of code, or extensive third party "validation" of large bodies of code beyond existing mechanisms (i.e., the Common Criteria) nor will it support a "custom code" development model where all developers are US citizens, any more than the marketplace will support US-only components and US-only assembly in hardware manufacturing. This was, in fact, a conclusion reached by the Defense Science Board in their report on foreign influence on the supply chain of software. And in fact, supply chain risk is not about the citizenship of developers or their geographic locale but about the lifecycle of software, how it can be corrupted, and taking reasonable and commercially feasible precautions to prevent code corruption.

Constraint 4: Any supply chain assurance exercise - whether improved assurance or improved disclosure - must be done under the auspices of a single global standard, such as the Common Criteria.

Discussion: Assurance-focused supply chain concerns should use international assurance standards (specifically the Common Criteria) to address them. Were someone to institute a separate, expensive, non-international "supply chain assurance certification," not only would software assurance not improve, it would likely get worse, because the same resources that companies today spend on improving their product would be spent on secondary or tertiary "certifications" that are expensive, inconsistent and non-leverageable. In the worst case, a firm might have to produce different products for different geographic locales, which would further divert resources (and weaken security). A new "regulatory regime" - particularly one that largely overlaps with an existing scheme - would be expensive and "crowd out" better uses of time, people, and money. To the extent some supply chain issues are not already addressed in Common Criteria evaluations, the Common Criteria could be modified to address them, using an existing structure that already speaks to assurance in the international realm.

Even in cases of "supply chain disclosure," any such disclosure requirement needs to ensure that the value of information - to purchasers - is greater than the cost to suppliers of providing such information. To that end, disclosure should be standardized, not customized. Even a large vendor would not be able to complete per-customer or per-industry questionnaires on supply chain risk for each release of each product they produce. The cost of completing such "per-customer, per-industry" questionnaires would be considerable, and far more so for small, niche vendors or innovative start-ups.

For example, a draft questionnaire developed by the Department of Homeland Security asked, for each development project, for each phase of development (requirement, design, code, and test) how many "foreigners" worked on each project? A large product may have hundreds of projects, and collating how many "foreigners" worked on each of them provides little value (and says nothing about the assurance of the software development process) while being extremely expensive to collect. (The question was dropped from the final document.)

Constraint 5: There is no defect-free or even security defect-free software.

Discussion: While better commercial software is achievable, perfect software is not. This is the case because of a combination of generally poor "security education" in universities (most developers are not taught even basic secure development practices and have to be retrained by the companies that hire them), imperfect development practices, imperfect testing practices, and the fact that new classes of vulnerabilities are being discovered (and exploited) as enemies become more sophisticated. Better security education, better development practices and better testing will improve COTS (and non-COTS) software but will not eliminate all vulnerabilities or even all security vulnerabilities -- people make mistakes, and its not possible to catch all of those mistakes.

As noted elsewhere, manual code inspection is infeasible over large code bases and is error prone. Automated vulnerability-finding tools are the only scalable solution for large code bases (to automate "error finding") but even the best commercially available automated vulnerability-finding tools find perhaps 50% of security defects in code resulting from coding errors but very few security design errors (e.g., an automated tool can't "detect" that a developer neglected to include key security functionality, like encrypting passwords or requiring a password at all).

Lastly, no commercial software ships with "zero defects." Most organizations ship production software only after a phase-in period (so-called alpha and beta testing) in which a small, select group of production customers use the software and provide feedback, and the vendor fixes the most critical defects. In other words, there is typically a "cut-off" in that less serious vulnerabilities are not fixed prior to the product being generally available to all customers.

It is reasonable and achievable that a company has enough rigor in its development practice to include, as part of a robust development practice, actively looking for security defects (using commercial automated tools), triaging them (e.g., by assigning a Common Vulnerability Scoring System (CVSS) score) and, for example, fixing all issues above a particular severity). That said, it is a certainty that some vulnerabilities will still be discovered after the product has shipped, and some of these will be security vulnerabilities.

There is a reasonableness test here we all understand. Commercial software is designed for commercial purposes and with commercial assurance levels. "Commercial software" is not necessarily military grade any more than a commercial vehicle - a Chevy Suburban, for example - is expected to perform like an M1 Abrams tank. Wanting commercial software to have been built (retroactively) using theoretically perfect but highly impractical development models (and by cleared US citizens in a secured facility, no less) might sound like Nirvana to a confluence of assurance agitators - but it is neither reasonable nor feasible and it is most emphatically not commercial software.

Book(s) of the Month

Strong Men Armed: The United States Marines vs. Japan by Robert Leckie

Robert Leckie was a Marine who served in WWII in the Pacific theater and also a prolific writer, much of it military history (another book, Helmet for My Pillow, was a basis for HBO's The Pacific). As much as I have read about the Pacific War - and I've read a lot - I continue to be inspired and humbled by the accounts of whose who fought it and what they were up against: a fanatical, ideologically-inspired and persistent foe who would happily commit suicide if he were able to take out many of "the American enemy." The Marines were on the front lines of much of that war and indeed, so many battles were the Marines' to fight and win. What I liked about this book was that it did not merely recap which battles were fought when, where and by which Marine division led by what officer, but it delves into the individuals in each battle. You know why Joe Foss received the Congressional Medal of Honor, and for what (shooting down 23 Japanese planes over Guadalcanal), for example. History is made by warriors, and everyone - not just the US Marines - should know who our heroes are. (On a personal note, I was also thrilled to read, on page 271 of my edition, several paragraphs about the exploits of Lt. Col Henry Buse, USMC, on New Britain. I later knew him as General Henry Buse, a family friend. Rest in peace, faithful warrior.)

I'm Staying with My Boys: The Heroic Life of Sgt. John Basilone, USMC by Jim Proser

One of many things to love about the US Marine Corps is that they know their heroes: any Marine knows who John Basilone is and why his name is held in honor. This book - told in the first person, unusually - is nonetheless not an autobiography but a biography of Sgt. "Manila" John Basilone, who was a recipient of the Congressional Medal of Honor for his actions at Lunga Ridge on Guadalcanal. He could have sat out the rest of the war selling war bonds but elected to return to the front, where he was killed the first day of the battle for Iwo Jima. In a world where mediocrity and the manufactured 15 minutes of fame are celebrated, this is what a real hero - and someone who is worthy of remembrance - looks like. He is reported to have said upon receiving the CMH: "Only part of this medal belongs to me. Pieces of it belong to the boys who are still on Guadalcanal. It was rough as hell down there."

The citation for John Basilone's Congressional Medal of Honor:

" For extraordinary heroism and conspicuous gallantry in action against enemy Japanese forces, above and beyond the call of duty, while serving with the 1st Battalion, 7th Marines, 1st Marine Division in the Lunga Area. Guadalcanal, Solomon Islands, on 24 and 25 October 1942. While the enemy was hammering at the Marines' defensive positions, Sgt. Basilone, in charge of 2 sections of heavy machineguns, fought valiantly to check the savage and determined assault. In a fierce frontal attack with the Japanese blasting his guns with grenades and mortar fire, one of Sgt. Basilone's sections, with its gun crews, was put out of action, leaving only 2 men able to carry on. Moving an extra gun into position, he placed it in action, then, under continual fire, repaired another and personally manned it, gallantly holding his line until replacements arrived. A little later, with ammunition critically low and the supply lines cut off, Sgt. Basilone, at great risk of his life and in the face of continued enemy attack, battled his way through hostile lines with urgently needed shells for his gunners, thereby contributing in large measure to the virtual annihilation of a Japanese regiment. His great personal valor and courageous initiative were in keeping with the highest traditions of the U.S. Naval Service."

Other Links

More than you ever wanted to know about sagebrush:

Speaking of profound misunderstandings, this: BitDefender created a "test profile" of a nonexistent, 21-year-old woman described as a "fair-haired" and "very, very naïve interlocutor" -- basically a hot rube who was just trying to “figure out how this whole social networking thing worked” by asking a bunch of seemingly innocent, fact-finding questions. With the avatar created, the fictitious person then sent out 2,000 "friendship requests," relying on the bogus description and made-up interests as the presumptive lure. Of the 2,000 social networks pinged with a "friendship" request, a stunning 1,872 accepted the invitation. And the vast majority (81 percent) of them did it without asking any questions at all. Others asked a question or two, presumably like, "Who are you?" or "How do I know you?" before eventually adding this new "friend." ... But it gets worse. An astonishing 86 percent of those who accepted the bogus profile's "friendship" request identified themselves as working in the IT industry. Even worse, 31 percent said they worked in some capacity in IT security....iang

19 posts left…

So Pyloris doesn’t work particularly well for port exhaustion on the server, but what if we can exhaust the connections on the client to better meter out traffic? That would make it easier for a MITM to see each individual request if it worked. So I started down a rather complicated path of using a mess load of link tags on an HTTP website trying to affect the connections on the HTTPS version of the same domain. No joy. It turns out that the limits placed on one port don’t affect what happens on another (at least in Firefox). So while I can exhaust all the connections to a domain over a single port I can’t do anything using HTTPS - or so it seemed (unless I was willing to muddy the water further by sending a bunch of requests that I knew are a certain size to the HTTPS site - which just seemed more painful than helpful).

Then, based on some earlier research I stormed into id’s office and I started bitching that there was no point in trying to stop port exhaustion if they were going to allow tons of connections, just over multiple sockets anyway. As the words came out of my mouth I realized I had come up with the answer - a ton of webservers. I guessed that there must be some upper bound of outbound connections and it’s probably at or less than 130. You should have seen id’s face as I asked him to set up 130 connections / 6 connections per socket = 22 web-servers for me. Hahah… I thought he’d kill me.

It turns out it’s nowhere near 130 open connections. Firefox sets a rather arbitrary 30 connection limit. So if you can create 5 open web-servers and exhaust 30 connections and only free up one long enough to allow the victim to download one request at a time, I think we’re in business. Makes sense in theory. The problem is that it’s REALLLLY slow. I mean… painful. In my testing it seemed more like the server was broken entirely from the victim’s perspective. But eventually… and in some cases I mean minutes later - it would load. I’m sure that the attack could be optimized to work based on the fact that no more packets are being sent when the image gets downloaded or whatever… which would signal the program to free up a connection. This is opposed to my crapola time based solution combined with chunked encoding to force the connection to stay open without downloading anything that I came up with for testing. So I bet this attack could work if someone put some tender loving care into it, but it was kind of a huge waste of time for me personally - and for poor id.

Incidentally, for those who have never seen or met id, and would like to know a little about the other side of webappsec that I don’t talk about much here (the configuration, operating system and network), you’re chance is nearing. There’s a rumor that he’ll be speaking at Lascon in October. He’ll be talking on how he’s managed to secure ha.ckers.org for all these years despite how much of a target I’ve made it. Should be fun.

22 posts left…

While thinking about the previous issue and listening to Jeremiah’s preso and talking with the guys at Microsoft I got to thinking about cookie clobbering. Let’s say that Microsoft thinks HTTP cookies overwriting secure cookies is a big enough problem to fix. Let’s walk through the use cases. Let’s say there is a separate place for secure cookies that can’t be overwritten by non-secure cookies. Does that mean two cookies are replayed in HTTPS space, or that the HTTPS cookie always wins? Okay… let’s say it wins and the secure flag cookie cookie is the only one sent. Well let’s not forget about Jer’s cookie clobbering script.

When an attacker forces overwriting of the cookie jar, they get the exact same effect. Now the victim has no cookies secure or otherwise if the global cookie jar stays the same size and it remains a LIFO system. So now you’re saying, well the attacker can just use a SSL/TLS enabled cookie clobbering scripts - you’re right! So now there has to be a per-site container… or something - and doesn’t that completely defeat the purpose of the upper limits on cookies anyway? Now DoS conditions become an issue with overwriting the disc with tons of huge cookies, and so on. Anyway… this probably needs a lot more thought, and I’m certainly not advocating “fixing” this, just to end up with a worse situation than we already have. But certainly secure cookies shouldn’t be clobbered by HTTP cookies - in my opinion.

23 posts left…

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.

The XML Security Working Group has published five working drafts today. XML Signature 2.0, Canonical XML 2.0 and the XML Signature Streamable Profile of XPath 1.0 are part of an ongoing effort to rework XML Signature and Canonical XML in order to address issues around performance, streaming, robustness, and attack surface. The Working Group has also published updated Working Drafts for its XML Signature Best Practices and XML Security Relax NG Schemas Working Group Notes. Learn more about XML Security.

Small- to midsized businesses taking the biggest hit, experts say, but consumer banking customers could be next in the bull's eye(author unknown)

My student Peng and I have been submitting lots of bug reports to maintainers of open source software packages. These bugs were found using Peng’s integer undefined behavior detector. We’ve found problems in OpenSSL, BIND, Perl, Python, PHP, GMP, GCC, and many others.

As we reported these bugs, I noticed developers doing something funny: in many cases, their first reaction was something like:

Please stop bothering us with these stupid static analysis results!

They said this despite the fact that in the initial bug report, I usually pointed out that not only were these results from actual tests, but they were from the tests provided by the developers themselves!  This interaction with PHP’s main developer is a good example.

What can we learn from this?  I take away a few different messages:

1. From the developer’s point of view, static analysis results can suck. As these tools become smarter, they consider more and longer code paths. In a very real sense, this makes their results more difficult to reason about. It should go without saying that bug reports that are hard to reason about are not very actionable.
2. The developers of popular open-source software projects are suffering from static analysis fatigue: a syndrome brought on by seeing too many bug reports from too many random tools, too few of which are actionable. If I made a living or a career out of static analysis, I’d be seriously worried about this.
3. Many developers are still in the dark about C’s integer undefined behaviors. This is a constant surprise to me given that GCC and other common compilers have evaluated “(x+1)>x” to “true” for quite a while now.
4. The best bug reports, by far, are those that are accompanied by a failure-inducing input. I think the reason that we’ve been running into developer confusion is that we’re telling people that their own “make check” is a failure-inducing input, which people don’t want to hear since when they run it, everything looks fine. Some of these problems will go away when our undefined behavior checker makes it into an LLVM release. Lacking the checker people can still reproduce our results, but only by manually adding assertions.
5. Developers are prideful about their projects. This is as it should be, unless it blinds them to useful bug reports.

Regarding static analysis fatigue, there can be no silver bullet. People developing these tools must take false-positive elimination very seriously (and certainly some of them have). My preference for the time being is to simply not work on static analysis for bug-finding, but rather to work on the testing side. It is more satisfying and productive in many ways.

My student Peng and I have been submitting lots of bug reports to maintainers of open source software packages. These bugs were found using Peng’s integer undefined behavior detector. We’ve found problems in OpenSSL, BIND, Perl, Python, PHP, GMP, GCC, and many others.

As we reported these bugs, I noticed developers doing something funny: in many cases, their first reaction was something like:

Please stop bothering us with these stupid static analysis results!

They said this despite the fact that in the initial bug report, I usually pointed out that not only were these results from actual tests, but they were from the tests provided by the developers themselves!  This interaction with PHP’s main developer is a good example.

What can we learn from this?  I take away a few different messages:

1. From the developer’s point of view, static analysis results can suck. As these tools become smarter, they consider more and longer code paths. In a very real sense, this makes their results more difficult to reason about. It should go without saying that bug reports that are hard to reason about are not very actionable.
2. The developers of popular open-source software projects are suffering from static analysis fatigue: a syndrome brought on by seeing too many bug reports from too many random tools, too few of which are actionable. If I made a living or a career out of static analysis, I’d be seriously worried about this.
3. Many developers are still in the dark about C’s integer undefined behaviors. This is a constant surprise to me given that GCC and other common compilers have evaluated “(x+1)>x” to “true” for quite a while now.
4. The best bug reports, by far, are those that are accompanied by a failure-inducing input. I think the reason that we’ve been running into developer confusion is that we’re telling people that their own “make check” is a failure-inducing input, which people don’t want to hear since when they run it, everything looks fine. Some of these problems will go away when our undefined behavior checker makes it into an LLVM release. Lacking the checker people can still reproduce our results, but only by manually adding assertions.
5. Developers are prideful about their projects. This is as it should be, unless it blinds them to useful bug reports.

Regarding static analysis fatigue, there can be no silver bullet. People developing these tools must take false-positive elimination very seriously (and certainly some of them have). My preference for the time being is to simply not work on static analysis for bug-finding, but rather to work on the testing side. It is more satisfying and productive in many ways.

There seems to be a significant, government-sponsored push for compulsory certification and licensing in the security industry. The wonderfully self-contradictory report from the Commission on Cybersecurity aside, Larry Seltzer pointed out that this very idea is also a major part of the proposed Cybersecurity Act of 2009:

"Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any [...] information system or network designated by the President, or the President’s designee, as a critical infrastructure information system or network, who is not licensed and certified under the program."

I agree that there are persuasive arguments to be made in favor of taking this step - but it is very important to recognize that the same arguments can easily be made in favor of mandatory licensing for almost any contemporary profession. Quite simply: in modern societies, people serving even the most mundane roles can and occasionally do cause profound losses or significant distress to others. C'est la vie.

There is a small subset of professions where the stakes are particularly high - for example, building engineers; and several classes of occupations endowed with unique social privileges or an unusual degree of trust - say, doctors, lawyers, or teachers. In all these cases, licensing probably makes sense - although quite literally, it comes at a very significant price.

In most other occupations, however, the situation is far less obvious - and the current regulatory practice is rather arbitrary. We usually license barbers and hot-dog vendors - but not bakers, farmers, or pacemaker assembly line workers. Electricians and plumbers are licensed - but construction workers do not need to demonstrate even basic competency to any external body. Louisiana has a tough test and mandatory licensing for florists. Many of these distinctions are driven by specific interest groups, some are fueled by moral panics; but they do not seem to form a coherent, cost-efficient plan to make our society a safer place.

The extra cost of licensing aside, the most significant pitfall of overzealous regulation is that in attempts to preemptively police complex industries or individual human behaviors, governments are necessarily clumsy and heavy-handed - and often fail to consider many of the socially valuable corner cases. Here's a couple of my favorite (if only vaguely related) non-IT anecdotes:

• To combat the proliferation of basement meth labs, Texas requires a license and a home inspection to buy a beaker. While this is unlikely to have any impact on real criminal activity, teaching your children chemistry suddenly gets a lot more complicated.

• In an attempt to curtail drug use, eleven US states require you to have a prescription to buy syringes. This has a significant impact on many types of precision hobbies, where syringes are indispensable as a measuring tool; and probably only promotes syringe reuse among drug addicts.

• Following reports of people pointing lasers at aircrafts, Australia and some other jurisdictions ban sale or import of lasers with output over 1 mW. This rule also covers more powerful but completely eye-safe lasers with integral pattern-generating optics - commonly used in machine vision and hobbyist robotics; the impact on these applications is profound.

In the end, it is a natural human instinct to try and minimize many of the perceived risks we are subjected to - but it's also important to seek sensible balance between this goal, and the task of maintaining our civil liberties, or enabling scientific progress. We can make our lives resemble one giant TSA checkpoint - but it's not a cheering prospect to contemplate.

So, yup: it is clear that bad software engineering may lead to real damage, and that the current situation is far from being perfect. There is also a potential for damage in getting a bad haircut, or being served a mystery hot-dog. In the end, however, I believe that in absence of truly exceptional circumstances and profound social benefits, we should be giving people the right to choose - and leave it to the industry to come up with the sort of meaningful professional certifications that it actually needs (if it needs any). Rudimentary liability for negligent engineering may be a far better method of improving status quo, by creating incentives to care about security - rather than having a certification system to hide behind.

Some of the urgency around this topic is fueled today by the end-times rhetoric about cyber-terrorism, cyber-warfare, and the imminent cyber-apocalypse - and the apparent shortage of qualified personnel to step up and save the day; but for most part, I do think this idea is very misguided. The landscape of information security, and the economics of vulnerability exploitation, have not fundamentally changed in the past 6-8 years or so - spare for a body of vivid anecdotes, and a couple of interesting but not surprising incidents; we also enjoyed a steady growth of a competent workforce, and a very self-limiting problem of charlatans. It is still the bored teenagers and the crazy geeks, and not the XSS-obsessed arm of Al Qaeda, that are the most significant threat to our infrastructure. True, government agencies are finding it unexpectedly difficult to hire the right talent, but some of the reasons for this may lie with the organizational challenges these entities are facing today - and not with the failings of the outside world.

...

Even if you disagree with the vaguely libertarian premise outlined earlier - that governments should not regulate professions in absence of exceptional social benefits of doing so - the other important question is whether there exists a body of stable, scientific knowledge that could be enforced as a part of a professional licensing scheme; if not, then the entire philosophical argument is moot. The apparent failure of commercial certifications systems - a fact confusingly pointed out and then subsequently completely ignored in the CSIS report - may offer an important clue: are the existing schemes inadequate and weakly embraced simply because people who administer them are incompetent quacks? If not, then perhaps, something more profound is amiss - and a new, shiny licensing scheme is not going to change that.

noreply@blogger.com (Michal Zalewski)

Rcbarnett:

- This is a template for submitting or documenting ModSecurity CRS rule/signature descriptions to
the OWASP ModSecurity Core Rule Set (CRS) Project.
- Project participants are encouraged to copy this template and create landing pages for each CRS rule
- Use this template and create a new page using the following format - http://www.owasp.org/index.php?title=ModSecurity_CRS_RuleID-XXXXX (where XXXXX is the CRS ruleID)

== Rule ID: XXXXX ==

=== Rule Message: Message Text ==

=== Rule ===
Provide the entire rule/rule chain here

=== Rule Summary ===
Provide rule background. What is the rule looking for? What attack is trying to identify or prevent.

=== Impact ===
This should be the Severity rating specified in the rule.

=== Detailed Information ===
Provide detailed information about the rule construction such as:
*Why the variable list specified was used
*A description of the regular expression used - what is is looking for in plain english
*What actions are used and why

=== Affected Software ===
If this attack only affects a specific piece of public software (if this is a virtual patch for a public disclosure) specify which info.

=== Attack Scenarios ===
Provide any data around "how" the attack is carried out.

=== Ease of Attack ===
How easy is it for an attacker to carry out the attack?

=== Ease of Detection ===
How easy is it for a defender to use ModSecurity to accurately detect this attack?

=== False Positives ===
If there are any known false positives - specify them here

=== False Negatives ===
Are there any know issues with evasions or how an attacker might bypass detection?

=== Corrective Action ===
Any tuning recommendations for the existing rule?

=== Contributors ===
Specify your name and email if you want credit for the rule or documentation of it.

=== Additional References ===
Provide any external reference links (e.g. - if this is a virtual patch for a known vuln link to the Bugtraq or CVE page).Rcbarnett