Palo Alto Networks PAN-OS Zero-Day Exploitation
volexity.com
volexity.com
"If you are unable to apply the Threat Prevention based mitigation at this time, you can still mitigate the impact of this vulnerability by temporarily disabling device telemetry"
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.
Isn't that just insecure???
Among reasons one might have seen them was centralised control plane, multipoint VPNs, yes deep-packet inspection (including for simply checking if the expected protocol was running on given traffic), they could be also simply used as pretty advanced router+firewall setup.
I'm just saying that not everyone used PAN NGFW for MITM proxying, and it's not necessary to enable/configure that to use them for other tasks.
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.
I had to talk to him and say look, what you're trying to do isn't possible without breaking things. It's not a limitation of the products, it's a limitation of the underlying security that you're trying to bypass, and you're making security WORSE, not BETTER.
He wanted to log every employee's Internet traffic so that he could determine if someone was leaking company data, such as source code, customer data, etc. I said that there's nothing you can do to stop that, and even if someone knows their traffic is being monitored, it's easy to bypass by just adding a second layer of encryption.
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 other team to ask them to work around that mess, and the solution is for the other team to do the thing in a different, much simpler way. I also ended up raising some even bigger security decision problems with the C-suite.
As one engineer from a different team told me (after they'd given notice of leaving, and kindly granted me an exit interview), the company had too many people making other people's jobs harder, for no reason.
A too-entrenched-to-fail-soon company might be able to justify that (say, it was the easiest way to check off a compliance box, with their encumbered velocity at implementing anything). Most companies aren't that, though.
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.
The fact is that security is a holistic concept and can ONLY be evaluated in context. That in turn requires good technical and operational knowledge. But people like that are rare and expensive, so instead we have entire armies of box-tickers who lack the intellectual capacity to even understand what a "tradeoff" means.
Something went terribly wrong around the mid-90s, when security changed from a discipline practised and understood by hands-on professionals into a consulting gig.
Disclosure: I've been doing infosec professionally since 1993.
1. put all assets into infrastructure you control, allow pulling only from that infrastructure, no exceptions.
2. understand your containers enough to be able to modify and manage their trusted CA / TLS chains.
You really ought to be in a position to manage your supply chain and you really ought to be in a position to manage what your containers trust. Certainly more work and inconvenient, and maybe not practical everywhere, but worth doing even independently of a middleware box, at least once you get to some level of "in production for reals"
The SSL forward proxy feature of Palos has a number of things that preserve the security of TLS connections, such as requiring a minimum TLS version, "passing through" cert errors like expiration or bad CN, and so on.
I've worked with PA firewalls for a while.
So you’re essentially admitting that these TLS boxes are more about controlling employees and “data loss prevention” than actually preventing real threats and doing honest security. Got it.
I think the parent commenter was pointing out that "MITM TLS box" has nothing to do with sshd scans. Not that MITM TLS boxes have no use.
Oh, and #4 on that "tenets of honest security" is an opinion not shared by all.
In the modern era of guest wifi and ubiquitous personal mobile devices, personal use on a work machine is not necessary or advisable. That said, in most places it is common to *not* decrypt websites related to health and government and banking.
Everything is about liability and protection of company data.
Personal use was not the norm. Locking machines down was. VPNs, corporate network perimeters, blocking copy paste (my god), TLS middleware boxes. It all sucks. And inspecting internet traffic is a breach of human rights among adults.
Then we grew out of it. Now we have identity perimeters. Strong identity and yubi keys, webauthn, SSO. Honest.security reflects how people operate today. Modern IT stacks operated by ethical teams don’t do traffic inspection.
We agree, TLS inspection is about control, not security. And that’s why it’s unethical.
“No personal use” also just doesn't work, ideologically. Gotta access your bank for payroll, financial stuff for 401k, RSUs. HR portal has to be accessible on the personal side too for taxes healthcare and emergencies. Been there done that move on.
I will concede that there are isolated highly security sensitive situations where full device control is needed like maybe for the employees or machines with access to a CA or production deployment keys or classified information with human loss of life at stake. But the no personal use mantra is not a blanket philosophy that’s healthy or good for modern society and isn’t relevant in 99.99% of use cases.
You can even look at MDMs which have shifted from full device control to hybrid support.
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.
Examples:
I was the regional IT director at an extremely large, French owned, financial organization that had a child pornography ring operating among a couple of employees and several outside entities. The investigation and apprehension involved the FBI.
At the same company: FINRA investigation into illegal insider trading at the commodities brokerage part of the company.
This stuff is going on all the time. Some of it involving law enforcement, national intelligence services (I have worked with fusion centers several times, too), and internal HR/legal.
You just don't know about it because you aren't in ops/secops/legal/hr/compliance.
You seem to be singularly focused on the software quality of the VPN. It’s important, but is far from the only aspect of security.
The company is worried both about keeping the bad guys out of their network and keeping their IP + secrets inside. The motivation for the TLS MITM blinks boxes is for the latter.
It’s easy as an employee to simply discount the value of decrypting your internet traffic, but the truth is that the company has a responsibility to protect against malicious insiders, malware/ransomware exfiltration, etc.
These boxes provide a one-stop hacker shop for all data exfil and malware injection that normally don't exist. In theory they can _sign security updates_, send fake announcements, just intercept, redirect and drop emails, etc. It's just too hard for me to understand how it's supposed to add security, unless these would be NSA endorsed or something.
Take a look at Palo Alto's applipedia[1], it has 4419 protocols/services that you can detect and write security policy for without decrypting anything.
One example, last week our firewall blocked a suspicious (but but in this case legitimate) site using DNS sinkholing, because the domain seemed suspicious (uncommon TLD + recently registered domain).
https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
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?
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.
This is an eyebrow raising feature, and one I hope that I would have had the foresight to disable.
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.
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.
It's great at finding people who can't remember passwords or misbehaving services or software.
It seems not allowing researchers even black-box access is their strategy to secure the platform.
There's an easier way to get a firewall spun up, though. https://aws.amazon.com/marketplace/pp/prodview-nkug66dl4df4i looks like the current version. I'm still running https://aws.amazon.com/marketplace/pp/prodview-3xtziatyes54i and can't speak to the newer option directly, but there should be something suitable on all of the big cloud providers.
If you're only using it for legitimate research, the licensing subtleties seem different than if you were using it for the benefit of its product features.
For people working in enterprise IT, word was (a least a few years ago) your salesperson could hook you up to purchase one their small boxes with a license, for home use. It's in their interest to have IT people familiar with their products. But (unlike whatever you bought on eBay) I don't know whether that license would have you agreeing to restrictions on research investigation, or to restrictions on talking about the product.
https://www.cdw.ca/product/palo-pa-440-security-appliance-la...
> Customers are able to open a case in the Customer Support Portal (CSP) and upload a technical support file (TSF) to determine if their device logs match known indicators of compromise (IoC) for this vulnerability.
They can't be serious...
https://live.paloaltonetworks.com/t5/general-topics/how-to-a...
AFAIK the forwarding engine is custom(ized), and on physical devices some of them offload to FPGA - or at least they used to when I administrated some 2014~2016.
The management UI was in PHP :P