Palo Alto:'These Are Horrible Hacks'

Watchtowr Labs

Connect With Us
---------------------------------------------------

Lawrence Systems Shirts and Swag
---------------------------------------------------

AFFILIATES & REFERRAL LINKS
---------------------------------------------------
Amazon Affiliate Store

UniFi Affiliate Link

All Of Our Affiliates help us out and can get you discounts!

Gear we use on Kit

Use OfferCode LTSERVICES to get 10% off your order at

Digital Ocean Offer Code

HostiFi UniFi Cloud Hosting Service

Protect your privacy with a VPN from Private Internet Access

Patreon

Chapters
00:00 Palo Alto CVE-2024-0012
01:36 Pots and Pans Watchtowr Write Up
03:04 The Bad Code
04:08 How The Bypass Worked
05:20 Could This Have Been Prevented?

[johnvillalovos]

As someone who's job is software development, someone putting a remark in the code that something is a terrible hack doesn't mean that management will be notified. It is usually a comment that this is ugly and would like to find a more elegant way to do it. It doesn't necessarily mean it is broken, though it might be. Take a look at the Linux kernel source code and you will find many comments saying that something is a "hack".

[etherboy]

We have quite a few PA firewalls and all management interfaces are on limited-access management networks. It amazes me that any organization with the resources for these firewalls would do this.

[davidkopack]

TLDR; Engineer explains in grave technical detail the issue to management, management quotes some project management best practices about shipping value. A CVE is born.

[traolin]

The ceo has a family to feed. Suggesting allocating their own, very limited pay to solve the issue is despicable. How dare you

[minifig]

Usually "this is an ugly hack" doesn't cause a massive security issue like this one. So, if no further argument was given, of course management ignored it. Wouldn't surprise me in the least if the manager in question got ~3 requests to fix "ugly hacks" a week. Perfect software is cost-prohibitive in most of the world we live in today. That premise is why Rust (the programming language) was created.
Maybe this should have been treated like an exception to the rule.

[guaripolo]

the same people in reddit looking down upon pfsense and stuff, are probably the same that just left the mgmt facing out lmao

[blackraen]

No, there isn't any reason. Bypassing authentication with a user-side supplied header value is not a hack or a solution; it's debugging code that should never be put into prod. This is a "ignore security" feature -- Someone wrote the code to do this on purpose knowing exactly what it did.

The discussion around externally exposed vs. internal doesn't even matter. An organization large enough to have a Palo Alto deployment (like ours) has a responsibility to secure tools internally, and this is literally the tool that provides defense against lateral movement in the network!

I'm glad I don't work on the security team cause having something like this live in a "security" product is really tragic.

[drooplug]

Defense in depth. This a reason for it.

[xephael]

With decentralized management sometimes it becomes hard to stop certain things... Especially if you're dealing with cloud connected stuff

[michaelhess]

Yeah, this is only an issue to those unqualified to use this type of device…

If you have a public management port open to the world, or anywhere but your most trusted network, you deserve what you get.

[enderish]

The continued enshittification of every service and system on the planet is hallmarked by the continued decline of good Q&A. This should have been caught considering how brazen it is.

[TazzSmk]

I think it raises the question of open source being potentially more secure, again

[SimonMcNair]

Hack means the same as workaround imo. Sometimes you need to get it out the door, and this just implies it could be optimised and/or more beautiful.

[JimtheITguy]

Imagine how many people are still just trusting that they have "The Best" when they leave management interfaces open to the world

[mcury]

I liked that banner, I'll include it in my codes.. 😂

[FastMellow]

This is a problem I have seen so many times. There is a fix, so someone writes a unit test that proves the code has some flaw. At the same time that person also writes a test that the intended behavior does not work. Another developer fixes the 'bug', but leaves a comment in the code (and most likely in the commit message). Nightly testing shows that the bug is fixed, the branch is squashed into a single commit to an upstream branch and because the unit, regression and end-to-end test shows everything is working as intended, a release build is performed.

The thing is that from the viewpoint of a unit test, a terrible bugfix is just a good as the greatest bugfix mankind has ever seen.

Now normally these type of things are caught during code reviews, but the reality is that not all code is code reviewed once it gets into the upstream branches. Most likely, the comment was also written in the related work item, but as it was completed, it got closed and nobody ever reads comments in closed work items...

[three-alpha-six]

I am not a PHP programmer. Still, I am not sure that the comment that you highlighted is actually the reason for that CVE. There is a check for that X-PAN-CHECK header as the first condition of the topmost if-statement so the problem might be up there somewhere (depending on what the else looks like).

Don‘t get me wrong: that code you highlighted is definitely fishy and should have been flagged in a code review. It is negligent engineering practice to not do that, especially for security critical systems.

[Latam-xr]

I’m sorry, but for this CVE I blame admins for leaving the management interface exposed to the internet really using the most expensive toy in your company ? is like letting your kids drive a Ferrari; anyways, no one is talking about the bigger issue Palos and many firewalls are written in PHP, one of the most insecure programming languages. Guess we're fine with securing our networks using swiss cheese code?

[WereCatf]

I could totally see someone making a hack like this temporarily as they're working on some feature, but they should have opened a high priority ticket in the issue tracker that prevents the release of the software until it is fixed. Temporary hacks are simply sometimes needed if you want to test a build on real hardware or such, but the whole point with them being temporary is that they get removed and replaced with proper solutions before final release. A big enterprise producing expensive hardware should have a proper issue tracker and if they don't, well, that's a bigger cultural problem at the company...

[scbtripwire]

Virtually every programmer is guilty of nasty hacks, it *sucks* when they reach production code. 😨