tssci security

Happy Two-Year Anniversary

Yesterday we celebrated tssci-security.com's two-year anniversary. I started this site on August 23rd, 2006 during my first internship, and oh my, how the time flew by. A lot of good things have come my way -- most as a direct result of this blog. The connections and many good times I've had with people because of this site, are countless and all priceless. Also a happy birthday goes out to Dre, which without, this blog would not have been as much a success as it's been. Dre celebrates his birthday on the same day as tssci-security's anniversary. A coincidence? :)

I know we've been pretty dormant the past several weeks -- I blame it on the security conferences. Tried not speaking out too much about the DNS vulnerability Dan found, since honestly, everyone has disagreed with each other and really nothing good came out of any of it. I've also been putting in 12 hour days at work for the past two months, which has been draining me to the point where I just want to chillax when I get home. There's really been no good security books come out lately for us to read, except for maybe Hacking Exposed: Linux 3rd Edition -- an ISECOM book. Speaking of ISECOM, tomorrow and Tuesday I'm attending a two-day training certification class for the OSSTMM Professional Security Tester. I've also got that Hacking Exposed book on the way, which I plan to read and possibly post a review up here. Supposedly it takes an OSSTMM approach to Hacking Linux... so we'll see. Expect to see some posts on the OPST tomorrow or Tuesday with my thoughts as well.

In the mean time, enjoy the following posts which I found to be interesting:

Posted by Marcin on Sunday, August 24, 2008 in Conferences, News, People, Security and Work.

Who's at HOPE?

Anyone here want to meet up? Message me.

Posted by Marcin on Friday, July 18, 2008 in Conferences.

Week of War on WAF's: Day 5 -- Final thoughts

Did we learn anything about web application firewall technology this week?

I hope so. However, my gut tells me there is an overriding feeling of ambiguity around this technology. People want WAFs, but they don't know why. Organizations everywhere think this is the best or only short-term answer to the web application security problem.

The PCI SSC, who has set June 30th, 2008 as the deadline for compliance with Requirement 6.6, also appears to be wishy-washy on the whole deal. I read the following two articles this morning about PCI-DSS Requirement 6.6 and the use of web application firewalls. While the titles of the articles may appear many are still leaning on or towards WAFs -- after reading the information and quotes, I think the titles might be misleading.

Web application security experts Mike Andrews and Robert Auger also have some interesting things to say. They seem to be very set on the idea that WAF (with proper blacklists) or VA+WAF (to manage the blacklists) are fair enough temporary solutions until organizations can implement secure coding.

Some interesting things can go wrong during the WAF implementation phase. I can identify the following problem areas that may have many organizations wondering why they went the WAF route:

  1. You think that a network engineer or network security expert could get up to speed quickly through training or lab-time. However, I think the average time to become a web application security expert is 3-4 years of specialization. Imagine how many developers could have been trained or worked on collaborative processes with IT security in that time period.
  2. Blacklist technology (especially VA+WAF) is going to help with false positives. However, what about general performance problems? If performance or availability issues occur, the first thing thrown out will be the WAF. What good is a device that is constantly removed from the architecture and then only put back in to meet compliance issues?
  3. There is a lot of technology out there to detect specific WAF products. It's been written about in books. Attack tools such as w3af utilize plugins such as detectWAF. Vulnerabilities exist in WAF products in the same way that they exist in all software. Adversaries are already using this information to their advantage. Using a WAF can indeed make you less secure. In order to provide a product that will protect modern web applications, we must first test the products ourselves. There is more complexity in the average WAF than in the average Intranet web application -- who is going to provide the countless hours of secure code review and manual pen-testing needed for these WAF products? Or are we going to use them blindly without considering the consequences?

What are some short-term alternatives?

  1. Multiple WAF solutions -- one solution that focuses on "outbound" web traffic, and another that is tuned to your specific application (e.g. language, framework, components in use, et al). If your web application uses well-formed, valid XHTML -- the outbound filtering requirement is already fulfilled. Refactoring your content to XHTML is a snap. Many books and tools exist to help in this process (Dreamweaver, xmllint, TagSoup, NekoHTML, and HTML Tidy just to name a few).
  2. A softer, lighter version of Agile/Test-first development practices with basic unit tests that correct input validation issues. This would be equivalent or better than WAF in practice. James Shore discusses how to implement this sort of idea in an article, Continuous Integration on a Dollar a Day.
  3. Even Aspect-oriented programming will show immediate value, as the cost proposition lowers when you already have the existing talent to implement AOP. If you have developers that know AspectJ -- input validation routines can be added with point-cuts almost overnight.

The problem with these three short-term solutions is that they involve talking to your development teams. Do they have a reason to avoid using valid XHTML? Maybe their waterfall mindset precludes them from being able to move to a situation where "building code" is more important than "programming" (although I would argue that it's a developer's job to write buildable code).

What I think is most sad about the state of WAF technology is that a single, cheap developer could easily replace all of the normal WAF functionality in the code using basic unit testing. A talented developer who knew AOP could do much more than a WAF, and still at a much lower overall cost. Some organizations that are implementing WAF are having the developers manage the solutions instead of network engineers or IT security. We're hoping that this situation will allow the developers to think up better ideas as well as learn where their applications are failing.

In fact, a non-developer: such as someone in marketing who uses Dreamweaver, could also do almost as much as a normal WAF by saving their content as valid XHTML. This would buy the organization basic application security functionality, which is what WAF also attempts to do.

Summary

We know that WAF's appear to be the easiest answer to the PCI-DSS Requirement 6.6. But what if there was an even more simple answer? Talk with your QSAC, QSA auditor, and an external third-party such as a web application vulnerability assessor, software risk expert, or strategy consultant about possible compensating controls, such as:

If you are going to choose a web application firewall, we suggest:

Rich Mogull also has some very new suggestions that he would like to see as a future for WAF in his blog post, The Future of Application and Database Security: Part 2, Browser to WAF/Gateway. It's also worth a read!

Posted by Dre on Friday, June 27, 2008 in Defense and Security.

Week of War on WAF's: Day 4 -- Closer to the code

[Andre and Marcin]: For today's post, we have a guest blogger, Rohit Sethi. We asked Rohit to do this guest post because we feel that his research, along with co-worker, Nish Bhalla, has been influential at solving some unique application security problems. We met Rohit and Nish at Shmoocon 2008 as fellow speakers -- their talk was our undisputed favorite as they did an outstanding job at presenting and conveying their message.

Their talk, Using Aspect Oriented Programming to Prevent Application Attacks [PDF] discussed how to take an existing application and add input validation (XSS, SQL Injection, etc), strong error handling, and access controls without ever changing the existing source code. We strongly encourage you to check out their work. Rohit also has a fabulous post for us today on WAF vs. Aspect Oriented Programming -- a warm welcome and big thank you to the great work he's done here! [ Cheers, TS/SCI Security blog ]

Web Application Firewalls vs. Aspect Oriented Programming

As a concept, the WAF (Web Application Firewall) is brilliant. It extends an application's trust boundary to include input from otherwise dubious sources. Fundamentally, it externalizes many security concerns away from the application's core logic. What makes the concept of WAF so appealing is that the technology addresses security as a "cross-cutting concern"; a part of the application that is pervasive across the code base yet rarely relates directly to the business logic. Other cross-cutting concerns, such as transactional management, coarse-grained error handling, and logging also end up diluting the code within an application away from core business logic (also known as "code scattering"). On a more practical level, WAFs can implement the security cross-cutting concern without changing existing source code -- meaning we can implement WAFs quickly and avoid destabilizing the application through code modification.

In practice, WAFs often suffer from a few drawbacks. In many organizations, WAFs are handled by an infrastructure or security team who are not intimately familiar with the applications that they're protecting. This often (though not always) ends up becoming an elaborate blacklist filter for malicious characters. Blacklisting is never ideal, but in the case of WAFs the danger is exasperated. The WAF and the application it's protecting are two different technologies. That means canonicalization attacks, such as sending malicious characters in illegal multi-byte or malformed UTF8 character sequences, may pass through the WAF interpreted one way and attack the application interpreted another way. This interpretation delta with disparate technologies is the same sort of problem that worsens attacks such as HTTP Response Splitting and HTTP Request Smuggling.

Is there a way for developers to protect their own applications without having to modify source code? Can you modularize the security cross-cutting concern without relying on an external application/appliance? Yes -- with Aspect Oriented Programming (AOP). At a very high-level, AOP is like applying Servlet Filters anywhere in your code (for more details, please see the article I wrote for SecurityFocus). Using the flexibility of languages like AspectJ, developers can choose the most appropriate layer (i.e. application design layer, not OSI stack) to protect their applications. A critical feature is that you are working with data as the rest of the application server sees it -- in its most canonical form. Unlike Servlet filters, AOP can be used to protect other interfaces like SOAP interfaces, RMI connections, etc. Developers can also to choose to delve much deeper in the code and protect, say, the basic Value Objects representing the application's data types by intercepting calls to the setter methods.

With a WAF, you can protect against SQL injection by stripping out malicious characters; with AOP, you can strip out those characters and additionally throw an exception/error anytime a dynamic SQL method is invoked. Perhaps more importantly, WAFs are almost useless at protecting against whole classes of vulnerabilities (e.g. missing server-side authorization on some critical functions) whereas AOP is extremely useful (e.g. transparently adding authorization checks to the actual business methods, independent of which interface they are called from). What's amazing about AOP is that you can implement these changes without actually modifying the source code -- one of the primary advantages of WAFs.

Is AOP always more appropriate than WAFs? Well, not quite. Similarly, WAF and AOP can protect applications when raw source files are unavailable. Both also require at least some application-level knowledge. However, AOP typically requires a deeper understanding than WAF. Without prior AOP experience, the off-chance of an implementation mistake is more likely to occurr with AOP than with a WAF.

WAFs are probably a better fit to protect those apps that are developed externally and/or for which you may not have the code/skillset to understand its internal workings. AOP is not an easy sell because it's poorly understood by most of the IT community. Don't expect the PCI data security standard to say "perform code reviews, use an application firewall, or implement security through aspect oriented programming" anytime soon. Another roadblock is that while AspectJ has been around for 11 years, few of the other aspect-oriented languages enjoy quite the same maturity and support.

All that being said, I'm sure Andre has made you aware of many of the shortcomings of WAFs (at least, compared to how they are being marketed). AOP is gaining traction in the developer community, as well as for security specific toolkits (check out Spring Security and see how they use AOP to implement method-level authorization). Later this year, we'll be hosting an open source project on useful security AOP aspects at Security Compass. For the time being, make sure to at least consider AOP as an alternative when modifying existing source isn't an option.

Posted by Rohit on Thursday, June 26, 2008 in Defense, People and Security.

Week of War on WAF's: Day 3 -- Language specific

This post comes via WAF thoughts from Christian Matthies's blog circa one year ago. Christian starts out with a bang:

[...] it seemed to me that quite a lot of people aren't aware of how effective such solutions in fact are. Basically I agree that different layers of protection [are] always a good idea to get at least close to a status that can considered to be secure.

In christ1an's post, The real effectiveness of current WAF, he speaks rather positively about WAF technology, but ends on a rather sour note:

[...] these solutions are actually doomed to fail by design [...] unless a Web application firewall is implemented exclusively for a specific language, it is very likely to be insecure and therefore using them should be well considered.

He makes some interesting points that you should certainly check out. Best -- this jives with what Fortify research on dynamic taint propagation discussed in their recent OWASP AppSec EU 2008 presentation, ` <http://www.owasp.org/index.php/AppSecEU08_The_Dynamic_Taint_Propagation_Finding_Vulnerabilities_Without_Attacking>`_Dynamic Taint Propagation: Finding Vulnerabilities Without Attacking [PPT]-- and paper, Watch What You Write: Preventing Cross-Site Scripting by Observing Program Output [PDF].

christ1an seems positive about Mario Heiderich's PHPIDS Monitoring attack surface activity [PPT] web application attack `detection' work (also presented at OWASP AppSec EU 2008). Fortify, on the other hand, seemed bullish on the CORE GRASP attack `prevention' project (also for PHP).

With regards to XSS and SQL injection attacks, this work is nice because as some of us know -- neither attack is primarily about input validation. SQL injection is a software weakness that can be prevented through parameterized queries with binding of all variables (thanks, Jim Manico, for this verbiage). Cross-site scripting (and particular variations such as HTML/CSS/JS injection) is a software weakness that can be prevented by output encoding (although for exhaustive methods, check out the work by Arshan Dabirsiaghi in the OWASP AntiSamy Project).

Now if we could only start to talk about the other 600+ software weaknesses and their root-causes and strongest defense strategies.

Posted by Dre on Thursday, June 26, 2008 in Defense and Security.

« Newer entries — 6 — Older entries »

blog comments powered by Disqus