If you're like me, you like to wonder about the theoretical impact of security problems rather than the likely impact. When we live in the theoretical realm, anything becomes possible! For example, standard best practices dictate restricting external access to management consoles. This simple and straight forward concept can be easily implemented on most modern enterprise platforms. So when PAN-SA-2016-0003/CVE-2016-3655 was announced March 2016 (with exploitation details), the following question stuck in my head:
Just how many consoles have the vulnerable API exposed to the Internet?
tl;dr
Palo Alto Networks Firewalls will respond to requests for the HTTP(S) login page with an ETag response header which can be used to fingerprint the exact software version running on the firewall.Firewall Background Info
Palo Alto Networks Firewalls typically are configured to host the default HTTP(s) login page on the same interface as the API for obvious reasons. The result being that if we can find an exposed login page, we theoretically should have access to the exposed API as well. The best case scenario would be to find a way to fingerprint an exposed Palo Alto login page, so that you can be reasonably certain the device is vulnerable and that you have access to the API.Finding Targets
Ideally, we'd be able to look in some major search engine to find the answer. The good news is Palo Alto firewalls will frequently (but not always) respond to HTTP requests to an open webserver port with an HTTP response header containing "Server: PanWeb Server". A quick look into Mr. Shodan and suddenly I have 14,248 firewalls to look at (as of 8/23/16). That seems like a lot of exposure for a networking device...Refining the Targets
The good news (or bad news depending on who you are) is that a large number of the responses were for Palo Alto Firewall's GlobalProtect Portal and not the standard device login page. The terrible news is if we DO find a way to fingerprint the firewall, we may be able to use PAN-SA-2016-0005/CVE-2016-3657 to compromise the firewall instead.In order to refine the search results to only login pages, I decided to take a closer look at the Palo Alto login page response:
After reviewing a few of the Shodan results, I noticed that the GlobalProtect Portal won't respond with an "ETag" header. And luckily for us, Mr. ETag is exactly what we need to fingerprint the device!
Abusing ETags
For the uninitiated, the ETag HTTP header is used as a cache control mechanism. The web server and client can reduce bandwidth by sending resource requests with the current ETag (client) and responding with the full content only if the ETag has changed (server). However if the requested resource only changes when the device is upgraded, you've opened a door for possible fingerprinting based on the ETag response.Palo Alto ETags
The above screenshot was for a PA-VM on version 6.1.0 and contains two different ETags "3aa9c-143f-5441970f" and "b53-601c-54419710". So let's take a look at a couple other examples and their ETags:Version 6.0.11
ETag: "308e1-141b-55ca969b"
ETag: "3bd11-6018-55ca969c"
Version 6.0.13
ETag: "38189-141b-56be9ad6"
ETag: "40344-6018-56be9ad5"
Version 6.1.0
ETag: "3aa9c-143f-5441970f"
ETag: "b53-601c-54419710"
Version 6.1.2
ETag: "24b83-143f-54c1b22e"
ETag: "388a1-6035-54c1b230"
Version 6.1.2
ETag: "38844-143f-54c1b22e"
ETag: "388e1-6035-54c1b230"
Version 6.1.10
ETag: "4cc3a-143f-56bd96e1"
ETag: "58a1c-60d0-56bd96ea"
Version 6.1.10
ETag: "1fb7f-143f-56bd8c3a"
ETag: "33ad3-60d0-56bd8c40"
Observations
1) The first field seems to vary widely within the same version, so it won't be useful.2) The second field appears to correspond to the Major version of the Palo Alto (6.0 or 6.1 in these examples).*
3) The first few characters of the third field appear to remain the same across Minor version of the Palo Alto.
4) Each field increments with the version update (this will help us guess for "unknown/new" ETags).
*The second field did change once between versions 7.0.4 and 7.0.5, but remained the same otherwise.
The Final Method
1) Build a list/database of all known ETag responses (just the second field and part of the third) with the corresponding version number.2) Scrape the login page response for the ETag field.
3) Compare the ETag response to the known database (with guessing based on observation #4 if needed).
