I'm back

It's been a while, but I'm back. I left my previous employer and started another job about six weeks ago and have been traveling quite a bit. I plan on posting more frequently now, so stay tuned...

Holding Companies Responsible?

Should companies be held responsible for vulnerabilities in their sites? What if those vulnerabilities didn't target the company itself, but the company’s customer base? Not so many years ago most application vulnerabilities targeted the site/server/company data. Vulnerabilities such as sql injection were exploited to steal the data stored in the applications database. Buffer overflows were exploited to execute arbitrary code to gain access or escalate privileges on the company’s server.

However, just within the past couple of years we have seen a shift in the target. The most prevalent vulnerabilities no longer target the company; they target the company's customer. Vulnerabilities such as XSS (Cross Site Scripting) and CSRF (Cross Site Request Forgery) are generally used to exploit the user's trust in the company’s site. If you are a member of the appsec community you know XSS vulnerabilities are everywhere. Estimates place it at around 80% of all sites are vulnerable to XSS attacks. In comparison, if someone told you 80% of the food you eat was potentially poisonous, would you feel safe eating anything at all?!

So where is the incentive for the company to maintain an appropriate level of security and the cost associated with it, if they are no longer the target? Even if their site was attacked and a percentage of their customer base was exploited, would the company disclose it? Would they notify their user base that their site was hacked and their customers may have been exploited or conned into providing personal/sensitive data that was actually sent to a malicious hacker? My gut reaction is "no", they wouldn't disclose it and they wouldn't inform their user base. Why? Why should they? They have no proof, even if they found a potential hack, that any customer was exploited by it. Plus, how could a customer prove the exploit came through the company's site and not one of the other hundreds or thousands of other sites the customer might have viewed?

The simple fact is companies have no incentive to prevent client-targeted attacks in their sites. The company isn't the target, they couldn't/wouldn't provide verifiable proof that an attack actually affected a customer, nor could the customer prove that the attack was from a specific site. Until there is some way to hold companies accountable for vulnerabilities in their sites, these types of vulnerabilities will continue to exist and exploit users. In the end, it's the customer who pays the price.

Why I hate WAF's (Web Application Firewalls)

I have never officially voiced my opinion on this technology, but I believe it's time I did. Why do I hate them? My reasons are below.

• They are used as bait to prey upon corporate security fears.



• They are a reactive approach that fails to address the underlying issues associated with application security.

Why they are used as bait:

WAF's are often look upon by those outside the security industry as the panacea of application security issues. Vendors tout their product will prevent this attack or that attack, often times scaring potential customers into believing they could be the next TJX, if they don't implement a WAF. Most security professionals would, as a part of any security assessment, discuss proper training for the development groups. Training such as secure coding practices, training on application vulnerabilities (XSS, etc...) and their impact. We may also recommend performing proper code reviews (not letting the blind review the blinds code!), as well as the purchase of static analysis tools and possibly security scanning software such as Sentinel from White Hat Security or WebInspect from SPI Dynamics. Both of which are very good at uncovering potential security issues in web applications. I think recommending a WAF to a company to solve their security issues should only be considered a last resort. RSnake has a nice write up on when a WAF might be considered an acceptable solution and it's really from a cost-benefit analysis point of view.

They are a reactive approach to security:

WAF's in my opinion are just really expensive ($60,000 - $100,000) band-aids. The application is an open wound and the WAF is the bandage designed to prevent infection from outside germs! If I were a CEO of a company, which I'm not because no one will return my calls, I would much rather invest that amount of money in proper training for my developers, instead of some metal framed box that is supposedly going to protect my company from a security breach. Looking at it from another perspective, implementing a WAF is almost like saying "Go ahead developers, create the application however you want, we'll protect it using this box!".

Personally, I would never recommend a WAF to any customer I consulted with, because I don't consider them long-term fixes, nor do they address the underlying issues associated with insecure software. Secure software starts with properly trained developers.

Shifting the developer/tester heirarchy

While performing a security assessment for a company recently, I had the opportunity to sit down with a QA group and discuss testing and how they view their role in software development. I have to say our conversation was a little disturbing, but not at all uncommon in the industry.

My first question was "Do you feel your work contributes to the quality of the application?". Their answer was a resounding "Yes", although they admitted there were times when the development time frame limited the amount of time they had to QA an application. They admitted that on at least one occasion an application had been pushed to their production environment without ever being properly tested. It should be mentioned the QA Manager inherited the team and most of the testers do not have a technical background. They stated when they were hired by the previous QA manager they were told they didn't need to be technical, they just needed "... to be able to type characters into fields and click buttons.". They stated they weren't expected to find defects in the applications they tested, they just needed to confirm that it functioned as expected. I was dumbfounded! Needless to say, as part of my consultancy I was asked to give a 2-day class over testing methodologies and techniques. They took to the class like kids to candy; eager to soak up every ounce of knowledge I shared. As a result of their desire to improve their skills and eagerness to learn proper testing, I expect that the company's software quality will increase 100% in the future. They were a great group to work with.

Traditionally, testers have always been considered the "bottleneck" in the SDLC. They are generally considered the archenemy of a developer, using their kryptonite testing techniques to find the developer's weakness and then proudly announcing to the world, "I've found a bug, developers ARE NOT infallible after all!!!". Unfortunately, more often then not, you will find some sort of dissension between development and testing groups. If for no other reason, it's the egos that are in conflict.

There has been a major swing in the industry within the last couple of years as well. Generally, testers have been considered "beneath" developers on the "food chain". Management has often been of the opinion that it requires no technical skill to test or to be a tester, and that most testers are just trained monkeys that click around the application and make sure it doesn't blow up. This is also why tester salaries have generally been lower than developer salaries, with the exception of security testing. Security testing is obviously a highly technical skill since it can involve the skillset of a developer to understand the code, the skillset of a tester to know what to test and the skillset of a hacker to be able to pinpoint a vulnerable area and see how it could be exploited.

Microsoft has taken a significant position in changing this attitude in the developer/tester heirarchy. They understand that the lack of testing results in low quality software (Windows ME anyone?!). They understand that although the developers write the code to make it work, the testers are there to find the defects before customers do. Each group has a different mindset toward the application. One group is there to make it work and the other is there to see if it can be broken. They are two pieces of the same pie, whose sole purpose is to ensure the application is functional and of the highest quality. Microsoft is pushing the equality (and quality) envelope in stating, through their actions, that testing is just as important as development.

If you are in the business of making software, it behooves you to get these two groups to work together and have them understand they are just two different players on the same team. The ultimate goal is to create the best quality software possible.

Application Inspection/Test Drive

Would you buy a car without taking it for a test drive or having a trusted mechanic perform a thorough inspection?

Would you buy a house without having it thoroughly inspected?

I would suspect the majority of people would answer a profounding "No" to both questions. There are major risks associated with both situations, besides no one wants to end up holding the "short end of the stick" if the risk becomes a reality. Car dealerships and real estate agents don't expect us to just blindly trust that the vehicle or home is safe and without defect. However, we see it all the time in the business world. Corporations expect us to just blindly trust that their application/website is safe and without defect.

What are the risks if you don't have the car or home inspected before you purchase it? Well, you could end up with a lemon or a money-pit. What is the risk if you blindly trust a companies application/website? Well, you could have your identity stolen, along with all you banking and credit card information and have your computer compromised and "zombified" (Is that a word? I'll submit it to Webster's later!) and become part of a botnet or have malware downloaded to your machine without your knowledge.

I've heard both sides of the "Full Disclosure" argument and I can understand their reasons for being for or against it. I don't recommend going out and maliciously attack websites, but I do believe we, as consumers, have every right to ensure our personal confidential data is safe and secure. If that means performing an "application inspection" or "application test drive" to ensure the application/website we are using is safe and without defect (by defect, I mean anything that could put the consumer at risk) then I think we should have the right to do so, as long as our "inspection" doesn't have malicious intent. It's obviously hard to approach a company about a discovered vulnerablity without them viewing you as some malicious hacker whose sole purpose is to destroy their industry reputation.

Some companies may view this as a violation of their intellectual property or they may view it as nothing more than malicious conduct. Whatever the case I think it's time for the consumer to take a proactive approach to ensuring companies are providing safe and secure services and storage of our confidential data. We need to start demanding better security from our service providers.

R.A.D Editor XSS Vulnerability

I recently discovered this issue while testing an application that utilized Telerik's R.A.D. Editor control. (http://telerik.com/products/aspnet/controls/editor/overview.aspx). The editor control, as mentioned by Telerik on it's website, "... is the leading WYSIWYG rich-text editor for ASP.NET. It can replace any TextBox with an intuitive Word®-like editor, which enables even non-technical users to visually manage HTML content.".

On the ZDNet website they state "Telerik RadControls for ASP.NET is the preferred toolset for professional web development."
(http://updates.zdnet.com/tags/Microsoft+.NET+Framework+and+Microsoft+ASP.NET.html)

Now we all know HTML content leads to issues, especially when the content is not filtered for characters that can have malicious intent.

Now let's take a step back and analyze how ASP.NET handles request validation. There is a property called "ValidateRequest" that can be set to true/false either at the page level or application level within the web.config file. This property when set to true, which it is by default, handles and prevents a lot of the validation that could lead to XSS issues. There is currently a known validation bypass vulnerability for which Microsoft is releasing a patch for on June 12, 2007. On the other hand when this property is set to false, it basically leaves the page/application (depending on where the property value is set) open to all types of injection attacks.

One of the benefits of the R.A.D. Editor control is it does not require the "ValidateRequest" property be set to false in order to allow HTML type characters, which by all accounts would lead developers to believe that it enables necessary functionality without sacrificing security.
The vulnerability lies in the url encoding that Telerik is implementing to allow for the HTML content.

If the text in #1 below were entered into the editor control it would render it back to the page as #2.

#1: < src="" onerror="alert('vulnerable to XSS!')"> (spaced for viewing) (See Image 1)

#2: %26lt%3bimg src%3d%22%22 onerror%3d%22alert%28%27vulnerable to XSS%21%27%29%22%26gt%3b

Based on what we see we can tell the control is url encoding certain content being entered. So what if we did this...Let's url encode our attack vector.

Now, < src="" onerror="alert('vulnerable to XSS!')"> becomes %3cimg src%3d%22%22 onerror%3d%22alert('vulnerable+to+XSS!')%22%3e.

When we place the url encoded text into the control, it renders as #3 on the page.

#3: %253cimg src%253d%2522%2522 onerror%253d%2522alert%28%27vulnerable%2bto%2bXSS%21%27%29%2522%253e (See Image 2)

based on this we can see they have url encoded the "%" signs so %3c became %253c.

Now using any HTTP request manipulation tool, such as TamperIE or LiveHttpHeaders we can intercept the request, and remove the "25"s from the attack vector (See Image 3), thus returning it to the original value we entered, upon submitting it back to the server we see it actually fires the attack vector (See Image 4).

So there you have it, the R.A.D. Editor control actually takes a page that wouldn't generally be vulnerable to an injection attack and makes it completely vulnerable to all types of injection attacks.

When I contacted the company about the issue, they like most vendors, placed the burden on the developer, stating "...it is partially the developer's task to verify it and strip potentially malicious content."

Although, I don't disagree with this, it is obviously a conundrum. While vendors are expected to provide better, more secure products, when those security features fail the vendor places the burden back on the customer. So in the end, you may be in an even worse position then when you started.