How does one prove that they're authenticated to the PAN-OS security product, one might wonder.

Simple.

You provide a "X-PAN-AUTHCHECK: off" HTTP header.

CVE-2024-0012, folks.
https://labs.watchtowr.com/pots-and-pans-aka-an-sslvpn-palo-alto-pan-os-cve-2024-0012-and-cve-2024-9474/

@wdormann 🤯

@wdormann And still, companies will continue to pay insane money to buy these boxes of high-end engineering.

@buherator
The best way to get really bad software is to pick something that costs a LOT of money.

@wdormann to paraphrase: good software is expensive, but bad software is even more expensive.

@wdormann an interesting Palo Alto thing is they're by far the most intrusive firewall vendor in terms of traffic - you build rules using app IDs rather than ports, it auto detects traffic, MITM TLS etc. It's really cool. Also... just how secure is that? Really?

@GossiTheDog @wdormann you can do rules using just ports, it's just not how they recommend you do it. I've had to do that a couple of places when the false positive rate became too high (chopping TLS connections at random) when new signature patterns dropped.

@Slater450413 @wdormann yeah, the point was more it uses deep packet inspection for everything - relies on absolutely rock solid security to process everything.

@wdormann eye opening. I thought that such appliances would be past shellscripts and PHP but I guess I was wrong

@meronz
You clearly haven't looked at expensive security products recently. 😂

Aside from the client-provided X-PAN-AUTHCHECK header being able to tell PAN-OS device that we're already authenticated, we also provide a userRole argument to createRemoteAppwebSession, which...

You guessed it! Specifies which role our authenticated user has (e.g. privileges).

Given the appropriate "user" and "userRole" values, we can get to the target code to trigger the vulnerability...

@wdormann lol

@cR0w
I know I said privesc by a cookie... but does a POST body count, to?
@wdormann

@varbin Sure. Have a real cookie as a treat. Everyone gets a real cookie as a treat. Nothing matters anymore with these horrible vulns waiting to burn us all. 😿

@cR0w
Oh no. Do you need a hug?

@varbin Always, but I'm good. I'm just so so tired from chasing all these trivial vulns in ridiculously expensive "security" products and it keeps getting worse, not better.

About this CVE-2024-9474 vulnerability, though... WatchTowr says it's privilege escalation, but the CVE entry itself says it's OS command injection.

As mentioned by WatchTowr, there are indeed specific command injection fixes in the updated release. e.g. in AuditLog.php, the argument sent to pexecute() is now escaped. But, the exploit results in code execution as root. There's no explicit privilege escalation in pexecute(), and nginx runs as nobody. If we make a PHP page that calls pexecute, that code executes as the "nobody" user.
So how do we get to root?

CreateRemoteAppWebSession.php calls panCreateRemoteAppwebSession(), but nothing is explicitly imported or defined. How does this work?
PAN-OS specifies that panhttpdmodule.so be loaded via php.ini. And in this module, panCreateRemoteAppwebSession calls panSwalAuthenticate, which connects to localhost port 10000, which is served by mgmtsrvr. Which runs as...
root.

Is this specific invocation of mgmtsrvr where the command injection as root happens? I'm not sure. TBH, I've lost my desire to dig much deeper.

On a PAN-OS box, sure, nginx runs as nobody. However, virtually EVERYTHING ELSE runs as root. So when there's a code exec bug in PAN-OS code, you'll probably get execution as root.

This PoC appears to be broken, which is perhaps about all we can expect from software vendors.

sit back down again and press play like nothing has happened

What's with the "/.js.map" addition to the URI in the first request to a vulnerable server?

Usually PHP installations will be set up with the web server to handle PATH_INFO as passed arguments to a PHP endpoint. For example, a request URI to /target.php/lol.wtf will result in the PHP web server treating "target.php" as the endpoint code to run, and passing "lol.wtf" as a PATH_INFO sent to PHP.

This is all fine and good, EXCEPT for when app authors configure the server to handle endpoints differently depending on what the URI target is. For example, I might say that targets ending in .txt are perfectly safe, so I don't need to do any of that pesky security stuff. So, if I configure my web server to handle requests targeting *.txt to do something, I need to realize that a request for /target.php/lol.txt is NOT a request that is targeting lol.txt. It is targeting target.php, and "lol.txt" is passed to it via PATH_INFO.

What's happening in CVE-2024-0012?
Palo Alto is handling locations that end in .js.map don't need to bother with setting X-pan-AuthCheck header values (no inclusion of proxy_default.conf)

The problem? a request to anything.php/.js.map will match the nginx directive for the location, but at the same time will be sent to anything.php. This isn't the first time such semantic ambiguity leads to vulnerabilities in software. The same technique was used to exploit OwnCloud's CVE-2023-49103:
By requesting "GetPhpInfo.php/.css", an attacker is able to bypass all of the Apache rewrite rules, since the URI ends in .CSS and CSS files are harmless. 😂

Except whoever wrote those rules was apparently unaware of Apache's AcceptPathInfo configuration behavior.