 I'm Ben Feinstein. I work with SecureWorks in Atlanta, Georgia on the Counter-Threat Unit. I'm also happily affiliated with DC404, Atlanta's local DC group. We've got a big crowd out here this year. And today I'm going to be talking about web application firewalls, how they relate to PCI compliance, and also focusing a little bit on the Mod Security open source web application firewall. So just to cover a little bit what we're going to be going over, WAFS, web app firewalls. Some of you may be familiar with PCI data security standard. This involves payment transaction processors here in the United States, typically. And there's a particular requirement in the DSS, or data security standard, known as requirement 6.6. We'll cover that in a little more detail about why, if you're in the security industry, either an attacker, a defender, hacker, you should care about why PCI is affecting all this. We're going to review Mod Security. We're going to go over some key concepts of the Mod Security web app firewall. We're going to cover some of the core rules that they release with their web app firewall. And we're going to do a few live demos. Unfortunately, the content injection demo is not going to happen today, but we will be demoing reverse proxying and embedded deployments of Mod Security, and we'll demo it blocking a few attacks as well. So some basics about web app firewalls. Basically it's essentially a firewall up at the web application layer. So it understands HTTP, HTTBS, and understands all the web services protocols, typically can do some XML processing, maybe XPath queries against XML. Typically these products or solutions will understand SOAP and XML RPC kind of protocols. A lot of these products will perform some sort of normalization or de-offer-scation of the request before they inspect it for malicious content. Typically these solutions will detect attacks. They have passive and active modes typically. So an active mode it's going to actually block the attack. A passive mode it's going to generate an alert for an administrator to deal with. And these products rewrite and modify the request as they go through them before it ever hits your web application. So that's where you get the security from and that it's going to basically defang these requests, either block them, normalize them, decode them somehow, and then pass them along to your web application. So ModSecurity is I believe probably the most widely deployed web app firewall right now. It's released under the GPL v2 in a community edition. There's also a commercial license. Ivan Ristich and some of his colleagues created this and it's been commercialized by Breach Security. They have a line of commercial appliances, management tools, and reporting infrastructure around their web application firewalls. The core rule set, which is really ModSecurity doesn't do anything without these core rules or without adding rules to it. So the core rules are released under the GPL v2 on the ModSecurity.org website. And also the commercial Breach customers get a, I believe they get a commercial rule feed from Breach that has some additional protections that are not available in the GPL core rules. So payment card industry. How many of y'all deal with PCI and payment card industry issues? So pretty good number of hands. I'm apologized for everybody else if you don't care. You don't want to know about it. But PCI is important because it's really driving the adoption of web app firewalls and the adoption of a lot of technical controls in the enterprise. So Pintestors, which are now known as QSAs, and we'll define that term, basically if you're a Pintester, PCI is going to be driving your business. It's going to be generating a lot of engagements for you because these companies now have this new regulatory compliance that they have to fall under. So as a Pintester, you probably need to become familiar with web app firewalls, how to detect them, how to fingerprint them, how to, you know, subvert them. There's a talk, I'm going to plug towards the end of this talk that's happening, I think later this afternoon, that's going to cover web app firewalls from a attacker's perspective. So this is kind of a little more of a defender's perspective here on web app firewalls. So if you're an IT security organization, you're going to be deploying web app firewalls because of PCI. And also, you know, the black hats out there, you're going to be subverting these things for fun and profit. So some basic terminology around PCI, there's all sorts of acronyms they've defined around this. So you have the PCI Security Standards Council, also known as PCI for short. And that's the organization of the major merchant banks, credit card issuing organizations, you know, Visa, MasterCard, those kind of folks. And they've gotten together in a consortium and they've tried to define the PCI Data Security Standard, PCI DSS. And this is a set of standards that people that handle payment card data have to comply with. So there's some other PCI standards that we're not really going to be talking about today. There's the PIN entry device, PEDS standard, and that applies to typically like an ATM machine or a POS system, you know, where you swipe and enter a PIN. So there's standards around that. There's also standards around payment application data. We're not going to really focus on those at all. So a QSA, a QSA is a Qualified Security Assessor. Now you have to become certified by the PCI Standards Council to become a QSA. And there's also approved scanning vendors, ASVs. And these are organizations that have been approved to provide web application scanning to detect these vulnerabilities that are covered under the PCI DSS. So an example of an ASV would be like QALIS. And I think, anybody from QALIS here? All right, no, they won't admit it. So PCI Data Security Standard V1.1. This is the standard that's out right now, it's the current version. So it has some very basic requirements, very high level requirements. Build and maintain a secure network. Okay, how do we do that? Protect card holder data. Maintain a vulnerability management program. Implement strong access controls. Monitor and test your networks. Have information security policy. These are the basics, okay? And under these basic areas, they have a whole wide range of requirements. So we're going to really focus in on requirement number six. Requirement number six tells people that they need to develop and maintain secure systems and applications. Okay, so 6.6 gets a little bit more specific, but this is still a pretty high level standard. So vendors need to assure that all their applications are protected against known attacks. So they're not even, they're not talking about zero days or anything, just known attack vectors. And they give organizations a choice of how to comply with this. You could either do code review, and that could be manual code review. It could be automated code review. And there's not a whole lot of clarity around what they mean by that. But also you can install a web application firewall in front of your web-facing applications. So the PCI council has kind of set this up as either or. You can do code reviews or you can do application firewalls if you want to do both great, but you don't need to. So on June 30th of this year, requirement 6.6 became mandatory before it was a nice to have. So as of now, people need to be meeting this requirement. So a little bit of off topic on what I think PCI all means. I got a minor in economics with my CS degree. So I kind of look at things and analyze things from an economic perspective. So I see PCI as really a way to reassign legal liability amongst the parties. And I am not a lawyer. If there is a lawyer that understands the PCI stuff, well, I'd love to talk to them. But my understanding is that the QSA assumes potentially unlimited legal liability. I don't want to spread the fud, but there's legal liability assigned to the QSA if there were to certify organizations compliant when they shouldn't have, okay? Also, this is really a rationale for bigger IT security budgets. It's somewhat dictating how you're going to have to spend the money. But it is a rationale for bigger IT security budgets. Another interesting way to look at it is could this be really creating a race to the bottom for applications approved scanning vendors? And I'll get into that in the next slide here. So what do I mean by a race to the bottom? So let's look at this from an economic perspective. If I'm evaluating, if I have to become PCI compliant, and I've decided to go with an approved scanning vendor to meet that compliance. So I'm going to evaluate the cost of that solution. I'm going to compare that with the solution's ability to find issues or its quality. I'm going to compare that with the cost to my organization of remediating the findings from that ASV. I'm going to look at the loss, annualized loss expectancy due to issues that it missed, okay? And I'm going to look at the loss expectancy due to issues I have chosen not to remediate. The real problem here is that there's no market differentiator whatsoever between a PCI stamp of approval from one ASV or another. They all have varying levels of quality. Some ASVs will identify more issues than others. But if I'm becoming PCI compliant, actually, economic, you know, a rational economic approach would say by the cheapest, lowest quality scanning vendor I could find. They will identify the least issues. I will have to mitigate a smaller number of issues. And if I'm hit with a loss due to unidentified issues, I'm going to write that off. But I'm PCI compliant. I spent very little on my solution. And I've identified very few issues because it's a crappy scanner. So some concepts of mod security. One main concept is the ability to do virtual patching or just-in-time patching. The idea there is that you have a web app firewall in front of your web application. It gives you another option when you're patching. Instead of having to patch the application, fix the code, whatever it is on the backend web app, I can apply some controls on my web app firewall to mitigate the threat from that attack without actually having to patch my web servers, okay? So it gives you a little more options of how to patch something. Maybe I could put some rules in real quickly to my WAF. And then two weeks later, when the change window opens up, I'm going to be able to patch my web apps. There's a positive security model. So what that is is your input validation envelope. You have to model your application, what input is expected for different parameters, and basically enforce that model. So if the ID parameter is only supposed to be a number, we'll only allow numeric digits in that parameter. If a date parameter is supposed to be year, year, year, month, month, day, day, then enforce that, okay? And don't let 4,000, you know, A characters slide by in your date format. The negative security model is basically try to enumerate the bad stuff, block the bad stuff, look for SQL injection, look for cross-site scripting, those kind of things, and block it. So in the real world, it's extremely difficult to achieve this positive input validation envelope. There's a wide range, most large organizations have a wide range of web apps out there. There's a lot of code running. It's a major task to model these applications, identify the parameters, and create that positive input validation envelope. Now there are some tools, and these products typically have learning modes, where they observe the web traffic on your application and try to build that positive input validation envelope. And I want to give a quote. I'm not sure who gave this quote, but it's from a white hat security white paper, and I just really liked it. So it says, when you know nothing, permit all is your only option. When you know something, default permit is what you can and should do. But when you know, only when you know everything, then you could do default deny, and only then. So that kind of sums up the difficulty of building this positive input validation envelope, as it's been called. So some more concepts around the mod security web app firewall. So mod security breaks down its processing into several phases. And these are phase one through five. And when you look at the rules language, they're identified by number. So the first phase, mod security is going to process all your request headers for that inbound request. It's going to match rules against the request headers. Maybe you have a rule that says, HTTP 1.1 must have a host header. If not, it's a protocol anomaly. Block that request. After processing the headers, applying the rules to the headers, mod security is going to go process the request body. So if it's a post, you may have some URL forming coded data in the request body. Or you could have a rule that says, get requests are not allowed to have a request body. Block that. That's no good. That's a protocol anomaly. So after processing the request, mod security is going to either block it or let's say it passes that request along to the backend web server. The web server process request generates a response. That response flows through the mod security module as well. Mod security is going to process all the response headers. Similarly, it's going to match all its rules against response headers. If that looks okay, it will match the response body. So this could be a place where you would do data leakage protection, for instance. You could look for SQL server error pages being returned from a request, filter that out and give them a plain vanilla 500 or whatever. So this is the place you do some data leakage protection. And then finally, after processing all the request and the entire response, you basically do logging or take action. So that's kind of the five phases of how mod security processes these request and responses. Mod security also has the concept of a transformation. So the cool thing about these is you can nest them or basically run them in serial. And some of these are very useful. One of my favorites is the replace comments transformation. This is great for preprocessing a potential SQL injection. So a lot of times your SQL injection will have SQL comments in it and that will break up the request. So this transformation will basically strip out any SQL comments and then present the decoded request to the rest of the mod security engine. It's got transformations for URL encoding and decoding, hex. The JavaScript decode is a very cool transformation. It actually is an implementation of the JavaScript decode function, but it's in mod security. So if you can identify a payload that's JavaScript encoded, mod security can transform it for you and then present the decoded content to the rest of the matching engine. You do uppercase and lowercase transformations so you don't have to worry about case and your rules. You can translate the whole request into uppercase or lowercase. That also affect how it's logged. You can take MD5s and SHA-1s of file uploads on the wire. So basically I could create a blacklist of files I never want to either be returned from my server or I never want to be able to be uploaded in my server. Mod security can reassemble the file upload or the return file and basically take a MD5 or SHA-1 of it and match it against your blacklist. Pretty cool. And also it can, one very useful feature is it can normalize URI paths. So if you have directory traversal sequences, you know, all sorts of strange directory traversals, it can normalize those into a nice standard normalized path that you can match against. So this is very, it's important to understand the transformations when you're looking at how to write rules and how to protect things with the mod security firewall. So the core rules, without any rules, mod security doesn't do anything. It just processes request, passes it through. It's basically, you know, running almost like a proxy. So the core rules are available from mod security.org, they're under the GPL v2 license. They offer some main areas of protection. One is controls around the HCP protocol. So you can detect protocol anomalies. Like I mentioned before, you know, HP 1.1 requests without a host header. Or a Git request that has a request body. Those are anomalies. And you can also use that to have a defined policy on the HCP protocol to enforce RFCs, for instance. It offers protections against some of the most common web attacks. So we're talking about cross-site scripting, SQLI, cross-site request forgeries, response splitting. And it's not perfect. Cross-site scripting can be difficult to detect because it's so mutable. But it offers some protections against these common web attacks. It also has some interesting features to detect automated requests. These would be crawlers, search bots, web scanners. So it can basically detect when the Google search bot is indexing your page. Why would you want to do that? Well, maybe I return completely different content when Google indexes my page than I actually host. It has some basic Trojan protections. So these would be Trojans on your network that are using HDP command and control protocols. So ModSecurity is able to detect some of these command and control sequences between HDP-based bots. And another interesting application is server error hiding or data loss prevention, data leakage prevention. So basically, you can mask the errors that are coming out of your server. My classic example here is a SQL server error that has an ODBC error string and all this stuff in there. You don't really want that being returned to the requester. And it may be a lot easier to block that kind of stuff with your web app firewall than to get all your developers to fix their code on the web app to stop throwing these ODBC SQL server errors. Also it can do some data loss prevention. You can look for certain content being returned, confidential, top secret, for instance, and block those responses. So to go over some of the key words in that rule language, so we have a number of rule language keywords to match on requests. It's the method. Let's get, post, trace, track, those kind of things. The URI, which is the entire, well actually ModSecurity offers a very granular way to look at the URI. You have the request URI, which is that whole string. You have the file name part of it, which would be after the question mark, I believe, in a URI with parameters, excuse me, before the question mark, so it'd be like slashindex.php. You got your query string, which would be the stuff after the question mark. Var equals value and var2 equals value, those kind of things. You could match against request headers, either the presence or absence of a header, the number of headers, the value of particular headers, and you could also match against the request body, so it's a post, and you want to look at the URL forming coded content in that request body, so you could match on that with that keyword. There's a number of other options available to match on the responses, so you've got response status, 404302500, there you go. You've got the response body, so that could be the HTML content or whatever it is that's being returned back from that request. Headers again, type content length, so you could basically say I don't allow files greater than 10 megs to come back off my web server, or I only allow text HTML to be returned, or I never allow JPEGs. You basically could think of any number of ways to use these parameters to control the web app traffic. So v2.5.x is the current release, most stable release of ModSecurity. With the release of v2.5, there are some interesting functionality around content injection. So there's two new keywords, prepend and upend. When I detect a request, it matches some rule for whatever reason, I can have the response basically have content injected in the response before or after, you know, the top or the bottom of it. So for instance, if someone's attacking my web app, who here knows who Billy Hoffman is? Browsers and JavaScript engines, they shiver when Billy walks in the room here. So you could take one of Billy Hoffman's like evil, evil JavaScript payloads and shove it back into the response and recount it to the attacker. So it also, we'll get into that a little bit later and talk about some uses of that. Anybody out there returning go see? And a ho core sick is a fast pattern matching algorithm. So basically they've improved the performance of the engine by implementing efficient pattern matching algorithms. And that really helps when you have large sets of patterns. It caches the transformations now. So before every transformation you went through, it would reprocess the transformation. Now it's actually caching the responses which can yield great performance improvements. Another awesome feature is GeoIP lookup. You can use this as a matching criteria in your rules. I can block, prepend, upend, content inject content based on your longitude and latitude. I can do it based on your country code, okay? So that can get kind of interesting as well. So GeoIP lookup is built in, it's an operator in the rules language. Another very cool operator is the loon checksum algorithm for credit cards. So there's actually a verify CC operator in there. If I can identify content that I believe may be a credit card number, I can run it through this verify CC operator and it will say yes, that matches the loon checksum algorithm so it potentially is a valid credit card number. That's pretty interesting. One of the more advanced features is PDF universal cross-site scripting protection. I don't know if you all remembered, I think it was last year, there was a pretty bad vulnerable in PDF where you could basically execute arbitrary JavaScript for any PDF file off of any PDF file hosted on your website using the pound tag operator. This was pretty bad. So what mod security can do is it basically protects all PDFs on your site by generating one-time use random URIs. It will redirect visitors from that URI to the PDF file and it will actually defang and flush any malicious JavaScript in your browser when it gets back. So that's a pretty interesting feature there. They also built the Lua scripting language in. So if you can't figure out a way to do something with the rules language, well you can write a Lua script to do it. So you can make very complicated rules if you want to get into the Lua scripting. So how do you deploy this thing? Well there's some various ways to do it. The most simple and it's typically for a smaller site would be embedded. You have an Apache HDPD instance. You're going to run the mod security Apache module within that instance and it's going to basically filter through mod security and hit your web application running inside that same Apache instance. There's also reverse proxy mode which is more typical to a larger web app. Either you can do this in the cloud or other ways. So you use mod proxy which is a standard Apache module. You configure it in reverse proxy mode. So what that means is traffic is being flowing through your WAF. The requests are flowing through your WAF. The responses are flowing back. You could achieve this through DNS configuration. So you could have a DNS record for your website that points to your web app firewall and your web app firewall has configuration so it knows where to point, where to proxy the request back to. You could also do network layer redirection, netting, IP rewrite, whatever you want to do to make that happen. So one option here is you can host this in the cloud. You could have a web app firewall that's protecting any number of websites and domains using Apache virtual hosts. And basically you do some DNS records, point the websites at your web app firewall, have configuration there so it knows where to send the request to based on virtual hosts. So in that sense you could do this as a software as a service kind of play. So just to show an embedded deployment kind of scenario, you've got the Apache web server and let's just say it's www.example.com. You've got a virtual host for that. So inside a web server you've got the virtual host, you've got mod security configured to proxy through and talk to your document route. So site visitor hits your Apache server, mod security receives a request. It processes the request and it says okay, this request looks good to me. After it processes it, it says the request is good, it passes it through to the document route. Apache processes the document route, returns the request through mod security back to the site visitor. That's very standard embedded Apache module kind of scenario. So what happens when an attacker comes along and wants to hit your web app? Well the attacker is going to send its request into mod security. Mod security is going to process it and it's going to say nope, no good. After that you're going to send Billy Hoffman back to go get the attacker. And Hilarity ensues. So just an example of the embedded deployment there. And I'll give you a live demo right here of an embedded Apache embedded deployment. I've got a couple VMs running here. This is my first attempt at live demos at DEF CON, so please be gentle. All right, right here I've got an SSH session to www.example.com, it's a VM running down here. I'm in my Apache XCHDPD directory. You can see I've got COMF.D linked to no mod security. So basically just a standard Apache configuration, mod security is not running. Okay, let me make sure I've got the current config running. All right, so I'm going to bring up a web browser here. All right, so what we're going to do is we're going to tail the Apache access long and we're going to hit it with a normal request. Okay, you just saw there, we just saw a request from client.example.com, hit Apache, get request for slash, and you saw in my browser it just loaded the default Apache page, okay? So now, remember we're still not running mod security in this environment yet. So let's send something that looks a little bit like cross-site scripting, right? Gets through just fine. Apache access log, hit it. Okay, it returns the example page. Well, let's turn on mod security, okay? Well, I should have done, yeah. All right, so mod security is running. Instead of tailing the Apache access log, let's tail the mod security audit log. All right, now we're going to do it, send a standard request without that cross-site scripting junk in there. All right, now this didn't block anything, this is the audit log. So it just shows you how it processed the request. There was no alert generated. This is basically to show, you know, step through what mod security is doing. Now, let's send a potentially malicious request, okay? Again, I'm going to put in that cross-site scripting stuff. Excuse me. Boom. So you see at the very bottom says cross-site scripting attack, right there. Well, there. And so that would be generated in your log. And if you look at my web browser here, I got a 500, okay? That was returned by mod security. If we go look at the Apache access log, it never even hit the document root, okay? So let's flip back to the slides now. All right, so let's talk about the reverse proxy deployment. This is a little more complicated deployment, but it's more typical of how you're going to actually do this in the real world. So you've got your web app firewall, somewhere on the Internet. You've got a site visitor, and you've got your web server, let's say, behind your standard network firewall. So okay. So if you try to go directly to the web server, you're going to get blocked. The firewall doesn't allow visitors to directly hit the web server. You have to go through the WAF. Now if you go through the WAF, you're going to see the request, hit the WAF, says okay. It's going to regenerate a request. It's going to go back through the Internet, through your firewall. It's okay. It's coming from the WAF. It's authorized. Your firewall is going to let it through. And then it's going to basically hit your Apache server. It's going to be processed. The response is going to go back through the web app firewall. It's going to be processed, and then it would be rewritten, normalized, and then returned to the visitor. So that's kind of how the request response flow works in a reverse proxy deployment. So let's do a little quick live demo of the reverse proxy stuff here. All right. So let's go to, here we are on the www.example.com. What I'm going to do here is I'm going to turn off mod security like we had before. So no mod security. And I'm going to hop over, I have SSH-2 WAF.example.com, different host. So you can see comp.d is linked to no mod security over here. And then if you look at, this is all the configuration you need to set up a reverse proxy. That's it. I'm not even using a virtual host here. I'm just saying slash, anything under slash, you proxy to www.example.com. This is WAF.example.com. And you're basically using mod proxy and proxy pass reverse mode. So that's all the configuration I've really got on the WAF. Just make sure our current configuration is actually running. What we're going to do here, flip back to www.example.com. I'm going to tail the access log. And I'm going to show you that when I do a request to www.example.com, it proxies through and you'll see a request hit www.example.com. We're not running any mod security here right now. So instead of www, I'm going to go to www.waf.example.com. Now remember in the background, we're tailing the access log on the web server, not the web app firewall. I just got the patchy file, boom. See the request came from www.waf.example.com. So basically that request was hit the web app firewall, was rewritten and sent to the web server. The response came back. Now let's go turn on mod security on the web app firewall. Actually first I'll show you the cross-site scripting attack. We'll make it through because we're not running any mod security. Okay. Got the example page. Hit the web server. All right. So now we're passing this through mod security on the web app firewall. Now let's go back over to here. We're still tailing the log. We're going to go here, do our request again. Lo and behold, hey, everything worked. That's a normal request. It went through the reverse proxy. Now let's try to do this malicious request. Got a 500. Didn't even hit. There's no entry in there. And the web server is a patchy log. If we go over here, we can see that last request generated a cross-site scripting alert on the web app firewall. So we just demonstrated reverse proxying, filtering out an attack, and basically letting normal traffic through. So let's talk about content injection in the last few minutes I got here. I want to give credit to David Kierzowski. I apologize if I did not do your name right. He's associated with the Canoe Citizen Group and basically he wrote this interesting blog post I've got linked there called Content Injection Act the Hacker. So he looked at Mod Security 2.5 and said, wow, this is kind of cool. I can inject content based on any of these rules. So you could do it for defense. You could do it for fun. Or you could hijack JavaScript functions, redefine alert as a logger, for instance. So really, with this capability, you've got almost a looking glass into the client's browser. You can inject arbitrary JavaScript code back into the responses. So an example of how to use this is we're going to inject a JavaScript applet called MyAddress. What it does is it runs the applet inside the user's browser and it sends a callback back to us identifying the browser's actual IP address. It's not going to be affected by NAT. So it'll be interesting to actually see their internal IP address. So here's the rules that you're going to need to do that. You turn on content injection. It's off by default. You basically say, you know, you set an alert variable, tx.alert, and basically you're matching on a tx alert in that security rule and you see it says prepend colon and you've got some stuff that's getting injected in there, an applet tag, MyAddress.class, and then it's a submission to grabip.php and it's going to grab the IP off the browser and return it in a parameter to me. So this is a snippet from the Apache access log when we do this. So you've got to imagine you've got a reverse proxy WAF at 10010 and you've got the attacker at 172.16.020. So the first log, the first entry there, that's your web app firewall, sending the request onto your web server or it's logging it. And you can see it's a scripting, document write, it's a nasty little image tag that's revealing the cookie to the hacker's site. So the next log is we returned that MyAddress.class to the browser and we see immediately afterwards a request hit our server with grabip.php and IP equals 172.16.020. So by injecting that script, I've just revealed the IP address of the attacker. So another thing that's getting a lot of buzz lately is vulnerability assessment or web scanning plus web app firewalls. So the dream is that you could have this automated vulnerability assessment on your web apps that automatically identifies flaws and writes WAF rules for you that just work. Until recently, this was not really feasible. Web scanners generated way too many false positives. A lot of the vulnerabilities identified were actually duplicates. And because of this, the rules that would be automatically generated had many false positives and many duplicates, so performance would suffer. Vendors are trying again now. I know White Hat Security, their Sentinel service, and F5 have a partnership now where you scan your web apps with White Hat Security's tool and it will automatically feed rules into your F5 web app firewall. I have never played with this in real life. I don't know how well it works, but people are attempting this now and I expect to see a lot more synergy, I hate that word, between VA, between vulnerability assessment and WAFs here. So as we're wrapping up, let's talk about the limitations of WAFs. They're not a silver bullet. A lot of things can't really be handled with these. So insecure cookie handling or potential cookie tampering insecure session handling. WAFs can do cookie encryption and decryption on the fly, so they can kind of handle that. The real hard one here is business logic flaws. Here's an example, a reliance on a predictable random URL that just provides authentication and authorization. So if you know this weird URL, then you can get to content you shouldn't be able to get to. So WAFs can solve this by URL encryption where it's basically proxying the URLs back and forth and that's kind of similar to how they're doing that PDF universal cross-site scripting protection I mentioned. But many flaws in business logic are extremely difficult to detect with automated scanning. They're even extremely difficult to detect with manual code review. These are the hardest bugs to find, business logic flaws. I think Jeremiah Grossman and a colleague gave a talk at Black Hat the other day showing how business logic flaws can be used to defraud organizations of lots and lots of money. Those are difficult to mitigate with a web app firewall. So some closing thoughts on the future of web app firewalls and these kind of things. So vendors are going to increasingly add WAF-like functionality to their products. You've got high-end load balancers, firewalls, IPSs, UTM devices. They're all adding web protection kind of functionality. I could even see WAF-like functionality being wrapped into malware. I mean a lot of these malware trojans already have SOX proxy functionality in it. So basically the attackers can proxy their traffic through your compromise host. So potentially they could add some sort of web app proxying functionality there. I'm wondering if we're going to see rogue WAF attacks or malicious WAF attacks where a attacker-controlled web app firewall is there and is basically intercepting your traffic, injecting bad stuff back into it. And this might be similar to like a WPAD, the Windows proxy auto-detection attack vector, or a WAF poisoning where an attacker puts some bad things into the injection rules. And also people are going to increasingly be releasing WAF bypass vulnerabilities. These things are getting deployed everywhere. Attackers are figuring out how to bypass them, subvert them, evade them. So you're going to see more and more of that. I'm going to give a plug for another talk that's going to happen today. Wendell Henrique, I don't know if he's here. Basically he's given a talk called Playing with Web App Firewalls this afternoon. And basically it seems to be more of an approach from an attacker's perspective, how to detect, how to fingerprint, and evade WAFs. And I went through his slides this morning and I tell you I learned a few things about how to fingerprint these things. So if you're interested in Web App Firewalls from an attacker's perspective or a pen tester's perspective, I would recommend you go to Wendell's talk this afternoon. I just wanted to give a thanks to Dr. Tangent, the DEFCON goons, and everyone who worked their butts off to make this happen once again. And I got to give greets to the DC-404 crew that's out here. We've got Dr. Chaos, Kayak, David Maynard, Scott Moulton, and Regener. We're all giving talks here at DC-16. And I got to give props to our very own Goon Decode, who's a great friend. And if you have questions about this, I'm going to be heading off to the Q&A room as I wrap up. But you can also email me questions and I'd be happy to discuss them with you over email. Thank you.