Like most NexGen Firewalls, Palo Alto has the ability to provide several ways to do URL filtering. I don’t profess to know how they do all of it. But hey, sometimes you don’t really need to know why something works when you are trying to hack something, you just know it works. So lets take a little trip down how to by-pass url filtering and see if I can get access to some files, more than likely nefarious ones, and pull off some shenanigans.

First, this is setup in my lab with a PA-220 on version 8.1.8-h5 code. But I have a feeling it covers all versions of code. And for the record, I have a feeling this works on any NexGen FW, so if you have an ASA, Fortinet or whatever, give it a try and let me know how it works. For the setup I have basic URL filtering enabled. That’s not really rocket since or important, what is important is I have another rule created that allows for specific URL’s to be allowed. For this I choose I found in many businesses, someone, typically an executive, needs access to a site no matter what, and so a rule is added to the FW specific to that URL and pretty much allows anything. I am going to walk through an example with http/https. I am not doing any ssl decryption, but I don’t think it matters because it works with http. So I have an allow rule for a specific URL, then followed by a block any rule.

As you can see, when I try to access my nefarious site, it is blocked.

First and the hardest thing to do is find a URL that has been white listed. In this example, I added a rule that was specific to two domains that are white listed using Palo Alto’s URL Category. Take a look at the rule below, its going to allow any application from the inside to the outside, as long at its in the Service/URL Category of “iPad-allow-url“. If we look at that URL Category it includes and

So all we need to do it point that domain name to another IP, my nefarious IP. We could try and hack the local DNS server, that’s one way, but if I could do that, I would have way more fun in general. The easiest way is to just add an entry in to the local machines host file. You will need administrative rights, but if you are like most organizations with workstations, you more than likely are not using WDE, which means you can get admin rights in 5 minutes. More on that in a later post.

So change your host file and save it as below:

Add the IP then the domain/host name
Make sure you flush your DNS so nothing is cached.
Ping the hostname and make sure it is resolving to your nefarious IP address.
Now I can access my site via http
And I can also access it via https

If I have some time, I would like to find other applications that can be bypassed. To be clear, I doubt this is a Palo thing and more NexGen FWs are susceptible to this. The odd thing is this works on ssl without decryption. I know what you are thinking, it can not decrypt traffic so it doesn’t know what it is. So the question remains, how does it block it if it cannot see the data or how does it allow it because it cannot see the data? SNI, maybe, but I haven’t had time to look into any pcaps yet. Again, I own it so who cares.


I got off my lazy rear and decided to dig into this. Turns out, the encrypted side the FW is looking at the SNI information. Unencrypted is just looking at the http headers. Both of which is created on the host side, so you can fuzz it however you wish….happy fuzzing!

dump of the https calls, see the SNI unencrypted in the packets on the client hello

Author: Sir McGruff

I like to use my imagination to break stuff. I guess that's why I have been involved in Offensive Security for several years. And I do mean both meanings of the work Offensive, hackers have no room for political correctness.

Leave a Reply

Your email address will not be published. Required fields are marked *