Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Palo Alto Networks PAN-OS Zero-Day Exploitation

volexity.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#31

Post by spudlyo »

FreakLegion wrote: post #22
spudlyo wrote: post #20

"Device telemetry collects data about your next-generation firewall or Panorama and shares it with Palo Alto Networks by uploading the data to Cortex Data Lake. This data is used to power telemetry apps, which are cloud-based applications that make it easy to monitor and manage your next-generation firewalls and Panoramas." This is an eyebrow raising feature, and one I hope that I would have had the foresight to disa…

There's nothing eyebrow-raising about the feature itself. It's off by default, lets you control which kinds of data you share if you choose to share data at all, and is mainly used for basic operations (e.g. tracking CPU load, concurrent sessions, and other relevant metrics over time).

I'm not entirely comfortable with a security device streaming telemetry to a third party. The kind of metrics that you're thinking of have historically been made available on management interfaces via SNMP OIDs assigned to the manufacturer.

Personally I'd much prefer to poll the device myself and keep those metrics in-house. This may seem like an antiquated way of managing network devices, but SNMP is a well understood, interoperable, standards-based protocol without vendor lock-in.

Futhermore, as we've seen, features like these expose a larger attack surface on the device. My primary worry would have been around it being used somehow in a data exfiltration scheme, but a root-level compromise of the device is the worst possible outcome.

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#32

Post by dcow »

unethical_ban wrote: post #13
numpad0 wrote: post #10

I understand that these products has market demands from paranoid but not IP networking related businesses, but I never quite understood the fundamental basic premise of Palo Alto, F5 Networks, Fortinet, etc. brands of "MITM TLS firewall" products. These firewall boxes are on-prem white hat Mallory, reverse-reverse-proxying all TLS traffic. And of course the Linux stack it uses has tons of RCEs and misconfigurations.…

The premise is that a business needs to know what kind of data is passing through its networks. SSL forward proxy (man in the middle) helps this by letting the firewall see contents of data, more thoroughly govern access to websites and subcomponents of websites, and so on. For example, with MITM enabled, a Palo firewall can grant access to the viewing of Youtube videos, but not the upload or commenting of them. It c…

Honest question: have you ever seen a corporate TLS middleware box stop an active threat? And I don’t mean drive-by crap like port scanning for sshd…

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#33

Post by betaby »

ok123456 wrote: post #14
vladvasiliu wrote: post #7

Earlier quoted context omitted.

They probably mean some Linux distro with no crapware on top. Seeing how this exploit seems to be PaltoAlto-specific stuff built on top of the basic OS, GP's approach sounds sensible enough.

Yes. This is what I meant. A GNU/Linux iptables2 firewall.

iptables2 == nftables I suppose

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#34

Post by jiggawatts »

blakesterz wrote: post #6

You can sort their announcements by CVSS here: https://security.paloaltonetworks.com/?sort=-cvss This is their 3rd CVSS 10 in the past 5 years and they've had quite a few more over 9s in the past 5-10 years. I have no idea how that compares to other places like them, maybe they're all like this?

I just saw another vendor’s core network router and firewall product rolled out to replace cloud native routing.

It uses public IPs by default with open ports to the Internet to route previously internal-only isolated networks. It uses “military grade” 96 bit encryption (lol), and similarly had a nine-point-something CVE in that endpoint.

It was forced upon us because apparently it was vital to encrypt the VM-to-VM intra-cloud traffic that was already mostly HTTPS. This cost merely millions of dollars and broke a bunch of stuff, slowed down that which it didn’t break, and had several brownouts and outages in just a few months since it was rolled out.

IT security is mostly snake oil sold by con-men.

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#35

Post by userbinator »

unethical_ban wrote: post #13
numpad0 wrote: post #10

I understand that these products has market demands from paranoid but not IP networking related businesses, but I never quite understood the fundamental basic premise of Palo Alto, F5 Networks, Fortinet, etc. brands of "MITM TLS firewall" products. These firewall boxes are on-prem white hat Mallory, reverse-reverse-proxying all TLS traffic. And of course the Linux stack it uses has tons of RCEs and misconfigurations.…

The premise is that a business needs to know what kind of data is passing through its networks. SSL forward proxy (man in the middle) helps this by letting the firewall see contents of data, more thoroughly govern access to websites and subcomponents of websites, and so on. For example, with MITM enabled, a Palo firewall can grant access to the viewing of Youtube videos, but not the upload or commenting of them. It c…

I run a MITM proxy for adblocking too, but haven't heard of any companies doing that with theirs.

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#36

Post by mistrial9 »

unethical_ban wrote: post #13
numpad0 wrote: post #10

I understand that these products has market demands from paranoid but not IP networking related businesses, but I never quite understood the fundamental basic premise of Palo Alto, F5 Networks, Fortinet, etc. brands of "MITM TLS firewall" products. These firewall boxes are on-prem white hat Mallory, reverse-reverse-proxying all TLS traffic. And of course the Linux stack it uses has tons of RCEs and misconfigurations.…

The premise is that a business needs to know what kind of data is passing through its networks. SSL forward proxy (man in the middle) helps this by letting the firewall see contents of data, more thoroughly govern access to websites and subcomponents of websites, and so on. For example, with MITM enabled, a Palo firewall can grant access to the viewing of Youtube videos, but not the upload or commenting of them. It c…

> a business needs to know what kind of data is passing through its networks

a business... without context this appears to be a "free" card for any amount of micromanagement or intra-company snooping.. locks on the cabinets with the cheap coffee in it.. that level of petty.. sure, there are larger objectives but the way this is said, there appear to be no checks and balances.. it could be like a fish-in-a-barrel snooping free-for-all.

as one reference, UC Berkeley put in "deep packet inspecting" mail servers more than 12 years ago.. to watch faculty email content.

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#38

Post by justusthane »

paleotrope wrote: post #25

Wow, 2 days for a fix, over a weekend.

Two days for a hotfix, but by the time we saw the notice of this CVE, PaloAlto had already pushed a content update that automatically blocks this vulnerability (provided you have the vulnerability profile applied correctly).

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#39

Post by FreakLegion »

spudlyo wrote: post #31
FreakLegion wrote: post #22

Earlier quoted context omitted.

There's nothing eyebrow-raising about the feature itself. It's off by default, lets you control which kinds of data you share if you choose to share data at all, and is mainly used for basic operations (e.g. tracking CPU load, concurrent sessions, and other relevant metrics over time).

I'm not entirely comfortable with a security device streaming telemetry to a third party. The kind of metrics that you're thinking of have historically been made available on management interfaces via SNMP OIDs assigned to the manufacturer. Personally I'd much prefer to poll the device myself and keep those metrics in-house. This may seem like an antiquated way of managing network devices, but SNMP is a well understo…

It does literally everything you're asking for though? The data is also kept on-device. SNMP is there. Log aggregators and log forwarding are there. Rolling up to a centralized controller is there. The vendor data lake is just one more option.

To be clear, this is a VPN interface that has to handle incoming connection requests and traffic. Exploits are super common here. The command injection happens to only work when telemetry is also enabled, for reasons I haven't seen explained yet, but it could just as easily have been SNMP.

Re: Palo Alto Networks PAN-OS Zero-Day Exploitation

#40

Post by xyzzy123 »

neilv wrote: post #28
WirelessGigabit wrote: post #12

Earlier quoted context omitted.

Company I worked at turned on MITM TLS for everything. Suddenly a lot of stuff stopped working, because not every piece of software on my machine uses the OS's certificate store. For example Docker containers who then curl to set up stuff.

One company had a related (but less defensible) decision, coming down from the top, which broke CI runners and other things, and the poor overworked Git&CI infra lead was trying to work around it. They asked me to be a Git reviewer for their big workaround, and I found around a dozen new vulnerabilities and future build-breaking defects that the workaround introduced. I also told them that it's unreasonable for this…

The root causes are usually among:

Security teams are often staffed by people who have no operational experience, and do not understand the consequences of what they are recommending or even mandating. Often those staff are blindly following hardening guides or asking for every configuration switch to be flipped to "most secure" setting without having a good understanding of the threat model for the workload and without taking into account the tradeoffs between utility and operational cost. The level of advice can be on par with ChatGPT or worse, but it is taken more seriously due to the advice-giver's job title.

Security teams often have no "skin in the game". There are no real disincentives to stop them from asking for crazy or very expensive things and imposing high costs on other teams. In fact they are incentivised to do that very thing, because the only thing that covers your butt more than recommending everything possible, is recommending everything possible PLUS some things that can't be done with the time & budget available, leaving them able to say "we see you had $security_problem, well, we recommended $impossible_thing but you didn't do it" (e.g. say, $500k of DLP solution [with its own operational risks!] for a workload that only makes $1M a year). To be fair I've seen some good & practical security teams but once you get a bad actor / games player at management level that behaviour can become very sticky.

I have seen variants of this nearly everywhere I've worked, it seems very hard to get incentives aligned between the do-ers and the secure-ers.

The most practical workaround I've seen is to make sure there is a reasonable balance of political power between the various parties.

"Reasonable" can be hard to establish but is context dependent. You would expect "Security" to have more power in an F500 because the brand value, financial and legal exposure are high and individual dev teams aren't necessarily across or exposed to the full consequences of the damage they can cause.

In a startup you would expect "Security" to have much less power because the consequences of not shipping / misallocating effort are almost immediately existential.

Post reply on HN