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???
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).
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.
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.
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.
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.
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.
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.
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.
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...
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
> 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://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.
"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"
