Breaking the Barrier: Exploring modern WAFs - Ethan Havinga

Uh so yeah, I just want to kind of start off just quickly just saying thank you to BISE, all the organizers. Uh what a great opportunity to be able to actually stand here in front of you and uh give a little bit of insight uh to people who are probably way smarter than me. Um so today we're just going to be delving a little bit into the complicated realm of WS. Uh we'll be kind of talking about a brief history of of where WAPs came from, the short uh evolution and why they've evolved the way they have. Um and then we'll we'll take a look at some cool bypasses um that I had time to research on and and

yeah, so before we jump into that, just a little bit about me. Um my name is Ethan Aankha. I am a security consultant at NWR cyber sec where I focus on the web application security side of things. Um my passion is overthinking edge cases. This usually lets like usually makes me find myself through some pretty deep rabbit holes. Um and then just the reason behind the madness. Um I think one of the main reasons I wanted to do this talk was generally generally on engagements you will have some sort of exception to any W in front of a web application. Um clients don't want you to be testing the W instead of the actual web application.

So you generally don't get to see or test a web application from the true perspective of an attacker. Right? So if that W was there um what extra steps an attacker would have to take to actually maybe compromise the web application. Um so you just generally don't get that full picture of uh uh when actually having that exception to a W. Um I also just spent quite a bit of time uh delving into WS. Um had some time to do some cool research and uh yeah I'm here to kind of share that with everybody here. So just as a small refresher uh for those that might not know or do need a refresher um we'll run through a quick

highle recap of what a w even is uh where you can find it and a web application firewall firewall or a w is usually a very small part uh from your greater web application environment. Um it's very easy to miss very easy not to give it the attention that it actually needs. um despite it actually playing a crucial role, right? So, it can in some cases mean the difference between a uh compromise and having that last line of defense uh that might deter attacker for a little bit longer. Um and the reason for this um the fact that it's a last line of defense is because it aims to reduce the exploitability of any underlying

vulnerabilities on a web application, which we'll get a bit more into later. So generally what makes a W special just a high level what can we expect it to do uh modern WS all have their own uh negatives and positives they do things differently um but we can kind of expect it to follow this kind of high level uh sequence. So obviously we wanted to hopefully monitor requests coming in um and then actually start analyzing the contents of that request coming in. Um then while it's analyzing the contents of the request, we kind of wanted to uh make a determination or match some content based of any predefined rules um or some predefined logic. So just for

those that might not know what a rule rule is, just to demystify that that the picture on the right there is a a screenshot from one of the mod security a-ource softwarebased web application firewall. Um just a small rule there just like kind of demystified. It's just that jumble of whatever that is and it does stuff. So uh then after obviously uh uh matching and analyzing content, we wanted to make a determination, right? It should either accept or reject that request. And hopefully in the case of a reject event, we wanted to obviously log that and that can then feed into other systems down the line. So w modern times. Um how did we kind of

get from brick walls to actual cyber shields? Um so we'll take a quick very brief not drawn to scale by any means um uh uh overview of the kind of history of wow. So in the summer of 1999 um appshield was released. uh this is really one of the first products to actually inspect incoming HTTP traffic, apply some primitive uh logic to that uh content and then actually uh make a determination on whether it was malicious or not. Shortly after that, mod security version one is released um as a module to the Apache HTTP server um that yeah was strictly for the Apache HTTP server that would kind of do the exact same thing. Then uh in a bizarre uh twist of

events, Appshield is discontinued. Um I do believe there's some conspiracy theories around this. Um good luck trying to find information about Appshield. There's about two paragraphs in the wiki in their Wikipedia entry and that's literally it. Um 2006 mod security version 2 is then released um with the inclusion of some a nice custom rule rule set development language that you could use to then actually implement your own custom rules. Then um kind of in my opinion one a very key key point in the evolution of WS um and how WS have evolved over the period of time we saw the emergence of cloud-based WS um things like Acomi and Cloudflare um being released and being

uh uh provided as a service. Then to keep up with that, mods kind of ported into lib mods um for better integration into other HTTP servers. Um and yeah, to just kind of keep up with the ever evolving cloud environment. Then for the present, uh I think especially with these the the new stronger AI and machine learning models coming out, um I think it's going to be quite interesting to see how we can actually apply the new in innovative technology coming out to WFTS and how they actually make determinations. So from brick wall to cyber shield uh software apps were not that good back in the day or softbased ws were not that good back in the day. Um they were seen

as glorified filters uh to some extent. Um I believe one of the main reasons for this is definitely the computational limits that uh were imposed on machines uh back in those days. So you couldn't have as many rules being applied to content um that is coming in until um cloud because cloud was seen as easier and way more scalable um and it was a lot easier to adopt a w into a larger state at that point because um a lot of people already migrating to massive cloud-based environments and it's also not onrem. somebody else is doing the hard lifting um paying for the machines that had a lot more uh computational power at that point. So we also kind of then see a a a

major shift in the techniques over the years that have been used. So from things like static attack signature detection, just some very primitive logic that you apply to content, um to things like behavioral analysis, really adding dynamic a dynamic aspect to the techniques that WS are using instead of the more primitive static techniques that u they used to use. And there's kind of a main reason for this or I believe one of the main reasons for this is um we've also seen with this um the the result of of of the evolution is because of a need for WS to keep up with ever evolving attackers and attack techniques and and those different threat actors because they've also

become more complex over the years and now uh everything seems to be AI powered in the modern days. Um, but really with the emergence of better and stronger AI and machine learning models, um, you've been able to actually, uh, see that being implemented to actually add a dynamic a add that dynamic, uh, aspect to WS, um, instead of again that static, uh, uh, static fallback that it would always rely on. And a wise man once said, uh, context is king. Um, not only have attackers become more complex and attack techniques, um, the web applications themselves have become more complex. Um, I mean, try explaining or count on your fingers how many times you've had to help grandparents or

parents actually use web applications because they have become a lot more complex. Um, their use cases have become a lot more complex and WS have had to generally keep up with that, right? where I should be able to differentiate at this point um in that complex environment between normal behavior and something that is not normal um which is a great task they have to undertake especially with the complexity of web applications within our time. So I just to run through before we get into kind of the juicy part um we need to kind of understand how to approach a W uh on on engagement. We need to understand how to approach it or is there a way to be consistent when

approaching WS um and have that ability to act to actually develop bypasses relatively consistently. I know we were talking about mindfulness and uh no stress stuff like that in the keynote. Um but the my personal methodology kind of goes completely against that. Uh so I follow a very iterative approach. This is generally my personal methodology. Um it's up to you if you want to take it. Uh so it just an overview of it. We start off by just obviously having a payload. um you want to create a bypass for this specific payload, chucking it in, see what the W detects, playing around with it, and actually having a list of things that that W actually

detects. Right? This we'll go into more detail on each step, but yeah, having that baseline, seeing what the W is actually detecting before we can actually continue. Then after you have that list of blocked elements per se uh to then obuscate obviously you want to uh uh perform obuscation and and and obuscation on the actual blocked elements. No point in obuscating parts of the payload that don't aren't really being detected at that point. Then the fun part testing um testing the payload and just seeing what happens. This is probably one of the the more fun parts. uh you never really know what's going to happen uh when chucking payloads at a WAF. And then this is the

part that kind of goes against the whole mindfulness thing. Um repeat repeat until you lose until you have a working bypass or you lose your mind. Um I have a very tedious and methodical approach to this. So again, this is not for everybody. if you want to go for it. And throughout while we dive through each uh each step, we'll have a little practical and we'll kind of just apply the the the the methodology to a practical example. The practical example is just a mock cross-ite scripting payload and we'll kind of see how the meth the method methodology kind of um applies to a practical example. Step one, identify. Um, this is really this is probably one of the hardest

parts trying it's really a game of where's Wally, trying to actually identify exactly what a W is u um picking up on. There's so much that a W can actually be detecting in your payload. Uh it does get frustrating at times um trying to find exactly what a W is actually detecting. But kind of a general guide, a high level guide on what things to look out for is obviously keywords. Um, looking for those keywords that I could be detecting combinations of characters and then obviously combinations of keywords and characters. So to kind of put this into perspective, our our example W uh is detecting the SVG keyword um as well as obviously a a

a HTML parameter which is obviously the combination of that space and then the word equals and then obviously the quotation marks and etc etc. So now we have a kind of a a list or we know what is being detected in our payload. Now we can kind of work on how to create a bypass for that. This is adults playing dress up. Uh there's so much that you can do. Um the limit is really just your imagination and keeping a level of syntactic correctness. Um that is a key point that I will stress throughout the talk. Um it's imperative that you do keep syntactic correctness. Doesn't help you obiscate a payload. It it bypasses the W

and then doesn't execute properly. Um so there's again a lot that you can do. Things like the OASP uh uh cheat sheets do help a lot if you want to look at those different techniques, kind of explore what you can do to payloads to maybe get them to bypass. Um but the general toolkit that you always have is always just character encoding. Um most have like a decent the the ability to distinguish um from your character encoding. Uh and then space manipulation. uh very big one trying to uh make it seem that your payload is one massive invalid HTML tag by replacing spaces with a character that might still be rendered properly when uh on an HTML

page, right? And then this is the rule logic flaws. Uh this one really speaks to things like SQL injection that we will get into. Um really trying to kind of catch the W out, right? trying to find things that the people setting up those default rule sets might have missed um and kind of using that uh to leverage uh in your journey of creating a bypass. Um yeah, do whatever floats your boat as long as it makes sense. I I'm not going to limit I'm not going to put out a standard. Um just generally just do whatever you want. It just has to make sense that syntactic correctness is a something you have to be mindful. So our practical um

this is actually one of the payloads we'll be uh talking about later in the bypasses. Um we determined that it was detecting that the combination of that tag and then space parameter etc. So what do you do? Eliminate the space. Um, this now to a WF looks like one massive HTML tag that's obviously clearly not malicious since it's invalid. Um, so why let it through? Just let it through. Um, won't do anything. And it really points out uh just below that the arrow pointing to we are still that is still the exact same payload that we started off with. Um, really keeping syntactic correctness. This is the exact same payload. It will execute the exact same

way. Um with the inclusion of now our RP station next step fun part um generally because you will never know what will happen um chances are uh it will not work the first time um but especially with this meth methodology or this approach um it's important not to really give up it it is very hard um since people have been doing bypass development people have been trying to create bypasses for ws for a very long time. So being able to find it, find new ones is very hard. Um it is going to be a very repetitive and tedious process. Um but just don't really give up there because uh at the end of the day it is like building

Legos. Um you are going to be taking away adding on um much like building Legos. So it is going to be iterative not just with my approach um but in general uh you will always be adding modifications removing modifications and going through that whole process and roadblocks are a guarantee. Um nobody has all the knowledge. uh you will feel frustrated at times. Generally, uh it's important to kind of keep that in mind and kind of acknowledge that roadblocks will will occur. Um you won't always think of different things to do and it's important to kind of take a step back and approach it from a a different perspective at times. But the most important thing is

just kind of keep going um until you either have a working bypass or uh you just lose your mind and completely give up. uh which has almost happened to me quite a few times u in my process. So now that we kind of know how to approach a w in hindsight um let's look at some of the juicy parts for the next two sections. We'll first go through some example payloads that are claim to be bypasses but don't actually get bypassed. Um so just to just a preface before we go through this uh I'm a sucker for default configs in a sense uh one reason is I believe during research this provides some uh form of consistency uh

and secondly uh the reason for uh the the default configs is a lot of organizations and people who might not be that technical will kind of look at web apps as plug-andplay. they'll just insert into their environment, leave it at def at whatever the defaults are and kind of assume that now their web application is safe. Um, so it's kind of quick and dirty security. Uh, basically so the WS that fall into my research was the Cloudflare W um the Azure gateway W and then uh the mod security uh software W. So the key difference between them is um the the first two are paid. Uh the last one is open source and free. Uh we'll see why

that matters in a second. Um and then by the defaults um I meant and for Cloudflare that means being on paranoia level one with a medium anom anomaly threshold. Then for Azure uh the stock standard implementation as per Microsoft's convoluted documentation. Um and then the default Microsoft managed rule set. Then for mod security um just straight out of the box as you get clone it. And then obviously these are just the core rule set that mod security does provide. We also have a nice little template um just to kind of show like payload whether it bypassed or not and then some pretty fun observations uh throughout the throughout the examples. So to start off with uh probably one of

the more common vulnerabilities, cross-ite scripting. Um most of these payloads that were block you'll find in again public word lists that kind of claim that this is a bypass word list. Run it through something like burps intruder and nothing works. Um so the first one there just being a mumbo jumble of character encoding, so URL encoding and HTML entity encoding. And then the second one there, um, much to my PTSD, J as [ __ ] Um, that basically means substituting normal human readable JavaScript for whatever that thing is. Um, and it still makes sense apparently. Uh, yeah. So, the third one there just kind of being more obscure tags. Um, tags that people don't often use. kind

of hoping that the WFT doesn't really uh have that in its let's say block list um or doesn't really understand that that is a valid HTML tag trying to get that through. So when it comes to generally XSS um to take J as [ __ ] as an example uh a lot of WS have rule sets specifically catering towards J as [ __ ] Um I did mention people have been doing this for a very long time. They've been doing this since WS have basically come out and finding bypasses is going to be hard. um especially for XSS because most WS do have it down to a T. And to get those bypasses, you're either going to

have to, I don't know, find uh uh logic flaws or do some pretty crazy things as we'll see. SQL injection, this is just for all variations. I don't discriminate. Um so the payloads here, they don't look that complicated. Um main reason for that is there's a very there's a fine line uh especially for SQL that has to be human readable and human writable. It's a very simple language. Um there's only so much you can obuscate the word select. Um there's only so much you can do to a SQL payload while still having it make sense and not return a a syntax error in the end. So like a lot of these you'll see with the bypasses kind of target again logic

flaws within the different WS. So for the first one they're just kind of chucking comments. Second one there just chucking around uh some brackets there trying to trying to abuse any keyword matching. Uh third one the exact same thing. And the fourth one just for shits and giggles just chucking everything at it trying to see what it does. and obviously all of them being blocked which is definitely good. Then some other common uh more niche vulnerabilities uh that you do see uh just to point something very interesting out um there's a CSTI payload, a XML external entity injection payload and then that CSV payload. Um by default uh CloudFare does not have rules to block the bottom two. Um, so yeah,

good luck if your web your web application revolves around XML. Um, enjoy writing custom rules for Cloudflare. So it really interesting to see that the more niche vulnerabilities aren't generally catered to um by default. Um, so if you do have that environment that makes use of functionality that could be targeted in for these vulnerabilities, um, yeah, you're going to have to look at either increasing that configuration, which a lot of people don't do, or increasing the the kind of strictness of your your your W, which a lot of people either don't know how to do or just don't do. Um, or you're going to have to start writing some custom rule sets. Now let's look at some payloads that

managed to bypass or just yeah funny things happening. Um cross-ite scripting starting with that again. Uh the first one there is actually the one we used during the methodology practical. Um kind of fairly heavily offiscated making it seem like one massive HTML tag. Um obviously when awf looks at that that does seem like a invalid HTML tag. So just kind of let it through it. no harm because it isn't even valid. Um, second one there, by default, Cloudflare doesn't block object tags. So, if you're an attacker and uh the your web app is protected by uh Cloudflare, yeah, have fun just injecting an object tag with whatever your payload is, B 64 encoded, just completely bypasses it. And then

that third one there was kind of an accidental one that I found. Um, I noticed that the Azure gateway WF was looking at open tags and opening closing tags, but not any HTML closing tags. Um, so you can kind of just start at injecting closing tags to kind of uh uh traverse the HTML hierarchy and actually inject content into different places on a web application. So for the example there, I managed to kind of just inject some content into the help section of a demo web application, which could open up some pretty cool things for for potentially fishing. So SQL now compared to cross scripting, these do look very simple. Um, but these are all exploit primitives. They are very

simple in nature. They do work by themselves, but they can also form part of bigger payloads. Now, granted, adding them to bigger payloads might get blocked because you are the other parts of the payload might be getting blocked. Um, but most of these are just fairly simple. Um, the the first one there, Cloudflare blocked the classic or one equals 1 when it was an integer comparison. Just changing it to a string comparison seems to completely bypass it. Um then again, CalFare did not block auto order by by default. So if that's a vector that uh is available to you, have fun. Um and then the third one there kind of again confusing any keyword matching u making that just seem

completely invalid uh to then obviously get that bypass going. So if you notice the trend um throughout the the the tables, mod sec mod security had almost no bypasses. Um this could technically just be a skill issue. Um I could have just not spent enough time on it, but I believe it's something a lot greater than that. Um and that brings us into the open source initiative. Um, I really think that in terms of something like mod security, this has been a uh a great driver for the evolution of uh of WS. I believe the benefits of this is massive. Um I I don't believe you can go wrong with uh uh with the act with uh the open

source or having a W that is open source and then getting people apes together strong getting people from getting people from uh all all walks in the cyber security industry coming together and applying their practical knowledge to a singular project. um which is not something you see happen often and it literally costs a penny and a packet of peanuts. It does it does not take a lot to get people in the cyber security industry excited for very often seemingly small things. Um, so getting people excited to actually contribute to things like this and actually then promoting attackers and defenders playing together, which is not something you always see is always that kind of fine line, that separating line between

red and blue. But where that breaks down is when you have open source projects like mod security for example that actually that allows you to then compile the the practical experience from both sides of the the spectrum to then further the capability of a w um so I really think this has been a a great driver um obviously we can't expect to cloud flare cloud flare and Microsoft to go open source within the next month but um I do think it has been a a great driver for for apps in general and kind of the whole uh cyber security industry for any tooling generally. So um kind of just before we wrap up um let's kind of take a detour

and address some misconceptions that you commonly see uh with the first of all implementation of WS and how people generally view WS. Um for that we need to understand the difference between mitigation and remediation. mitigation, gaslighting yourself into thinking a vulnerability is fixed. Um when in in reality, you're just making it harder to exploit an underlying vulnerability. Uh WS do not remediate. Um they make it that's why bypasses exist. Uh by that logic, WS are a mitigating factor. Um, it's fairly common to see people using it as a solution. Uh, slapping a W in front of your your web application and saying, "Ah, it's secured. Let's just leave it like that." When in fact, in in reality,

it should be seen as a last line of defense and not really as a solution to fixing anything, right? So prior prioritization should always be put on remediating vulnerabilities and kind of learning from that and applying what you learned during that process of remediation and maybe developing rule sets and applying what you learned then to the actual web of sitting in front of your web application because it's again all too common to see individuals or organizations especially individuals um that something like use something like Cloudflare which it does cater to something like your personal blog for example and they might not be super technical and just implement that W and kind of assume that their web

application is now secure and impenetrable when it in reality it's definitely not. Another thing you do see a lot is the implementation of custom crypto and how does this kind of affect uh a W if there is one in your environment. Um, webs are not smart. Um, they don't have the ability to decrypt custom crypto. Uh, main reason for this is they were developed by third parties to be used as a third party service. Uh, they were not developed with any of your custom cryptography in mind. Um, so it's really imperative that you be cognizant of in what state requests are hitting WS. if it hits a W in a encrypted form, it's not going to be able to actually decrypt

that and perform its job. This inherently defeats the purpose of a W. Um, and it is something you do see uh uh in some architectures uh every now and then where you really have to be cognizant not just for custom crypto but any just the general implementation of a W. You have to be cognizant of where is content hitting your W in what state is it hitting your W? Can the W actually perform what it's meant to do uh when content actually hits hits it at that point. So just for the last slide um there just some key takeaways that we just to like run through what we kind of talked about at a high level.

Um, we talked about, well, we just refreshed the hacker vocabulary. We kind of just talked about, okay, what is a WF? Um, the general history of WAFTs. Um, and then we jumped straight into grade 8 history lessons and kind of talked about where WS came from, why they why have they evolved the way they have. Um, I think also grouping in the open source open source portion in this is does adjust is um where you really see uh a lot of innovative technology coming from open coming from open-source um projects and and then we kind of looked at just my kind of weird methodology or my my weird approach um again I don't recommend it to anybody

unless you want to up to you um at potentially achieving consistency uh running through that very tedious process and I think a very big takeaway for this is to kind of look at it and find something that works for you. Um it is called a personal methodology for a reason. Um it does not work for everybody. Everybody do they they do things differently and it's really about finding uh that thing that actually works for you. We then also kind of again touched on that open source initiative where when red and blue come together they do amazing things. Um, it's a it's a line that's always kind of bothered me. Um, where there's always that separation

between red and blue and having something like mod security being open sourced where you can get both of those parties together and actually contribute to the the actual capability of something used by um by the greater community is something really cool to see. So we also then just quickly put WS in their place to some extent. Um, we talked about, hey, WFTS do not fix vulnerabilities. They are mitigating factors. Um, they probably won't ever fix vulnerabilities. And kind of being cognizant of where you put your W. Um, making sure that your W can actually perform what it's supposed to do. It can actually perform the job. and and yeah, generally just as a another takeaway just really driving home the

the the mental aspect of it, especially with the methodology is it is hard to approach a WAF. I feel bad for attackers when they have to uh they look at a web application that does have a WAF on it having that methodology. It is very tedious. Um but it is in the end technically uh uh possible to achieve some level of consistency uh especially in the case where you might lose your mind. But yeah any questions? Yeah. Yeah. Yeah. Yeah. I would generally want to go into more. um I think it would be really really nice but again my methodology kind of makes it a very slow and tedious process. Um so those three were all I had the ability to do within

the time I was given. Yeah. Yeah.

Yeah. um that happened so much. Uh it it's it's and it's I think it's really cool to actually see, right? Um maybe it's an like putting it in the shoes of an attacker, right? Um sitting in front of the W and that he the attacker trying to see if that vulnerability actually exists and then the W coming in and blocking that after the fifth attempt without the attacker actually having the ability to then confirm that it actually existed. really fun to see. Very painful. Um, but yeah. Anymore? Yeah. I spun a wheel. Um, no. Um, I think I I chose Cloudflare cuz mainly it's kind of what I see a lot of people use on like personal blogs,

for example. Um, it's something that a lot of nontechnical people can really actually use. It's not that hard to set up. Um they have a really great guide. So it's something you see less technical people to some extent use. I'm not saying that people using Cloudflare are not technical. Um please don't sue me. Um the second one obviously is just Azure. So that is catering toward towards the more enterprise level uh environments. And then mod security because it's open source. Kind of wanted to make a point. Um but yeah uh just also having that free alternative seeing how the free alternative compares to the paid and more I guess enterprisegrade ws. Cool. Any more? Oh yeah. I don't

know. And the second part is what you think about

authentication to the W. Yeah. Yeah. Yeah. Definitely. I I guess. Yeah. So having like let's say a cookie that's like authenticated. I'm assuming that's what you mean. Yeah. I mean there's there's a lot of like technical things that that are like being worked on like I I did mention in the history part of it. Um it's really cool to see how new technologies and how it is kind of evolving constantly. Um I think that's one part of of WS that always impressed me. It's constantly evolving especially now with new technologies being uh uh created and yeah I I I think that could be a cool idea. Any any last questions? Cool. Thank you everybody for

coming to my talk and uh enjoy the rest of the [Applause] sides. Across the attack surface scattered products and siloed views create blind spots that feel unstoppable. The deadliest risks are in these gaps where attackers move in. It's time to unify fragmented snapshots into one allseeing view of risk and unleash a platform born with one intention. Isolate and eradicate your priority exposures. From IT infrastructure to cloud environments to critical infrastructure and everywhere in between. This is tenable. Your exposure ends here.