"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"
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.
Modern L7 firewalls do a lot more than just MITM, and they can do it without MITM.
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).
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 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.
> but the truth is that the company has a responsibility to ...
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 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 can also scan files for malware, do analysis on shady looking javascript, and run DLP and credential checks to make sure no one is accidentally sending sensitive data to the wrong site.
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.
> 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.
As someone that I have worked for years with this kind of products in a couple of F500, I hate them with all of my heart.
I really prefer the approach based on DNS and IP filtering, it's easier to manage and doesn't have all the problems that SSL inspection has.
In case of Palo Alto Networks TLS interception wasn't the only, or even main, use in many places.
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.
If you have a TLS MITM proxy configured and an attacker pwns the proxy, it’s pretty much game over. Forget access to the internal network: any host that has the MITM proxy’s certificate installed will trust it to view and modify all TLS traffic. This gets a free attack on all web origins without even compromising anything else. AWS console, check. Configuration of other corporate appliances, check. Everyone’s communication tools, check. And you get to replace anything downloaded by anything that doesn’t use certificate pinning.
Global Protect is up there with Citrix Netscaler and Fortigate SSLVPN in the list of "secure" remote access products that no organization should be using without considering the fact that another easy RCE is going to come out roughly every 12 months and possibly lead to a ransomware incident.
A MITM TLS firewall product by Palo Alto Networks who hire employees for Unit 42 based in Israel who are definitely overseen by IDF, Mossad, NSA. There is a backdoor in every one of their products. And sending "telemetry" data to PAN is just a "security" ruse to further digitally fingerprint the end users. With so much i/o data and overwhelmed dev teams, these CEOs/CSOs trust &
surrender the keys to their company to intelligence agencies by proxy. Then when these intelligence agencies want to sink the stock of these companies they flip the switch with a ransomware or other zero day, which they'll blame on china, to keep the cyber attack fear alive, prospering whatever other companies they have in mind. Plus gathering immense amounts of data on all operational aspects of that company, which then can be sent to investment group BlackRock's super computer "Aladdin" for further manipulation and control. Think about it, a MITM TLS appliance, own by a 3rd party, sitting in the middle of a conglomerate company's network. Real stupid.
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.
"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 disable.
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.
Telemetry is pretty much the norm for XDR. The problem is all this stuff is cloud and not on-prem. Wazuh is great for on-prem, but the profiliferation of SaaS, etc., makes it extremely difficult to keep a handle on everything.
My feeling is that Wazuh is of little use to anyone besides those aiming to please security auditors, for whom it provides file integrity monitoring and other 20th century best practices that predate our modern world of virtualized short-lived servers.
I've been trying to get a copy of panos for fuzzing/research myself but unless I set up a reputable llc that seems impossible. They've ignored every request for purchase I've made. If anyone has tips on how to get started with this do let me know.
It seems not allowing researchers even black-box access is their strategy to secure the platform.
If you're trying to buy from them directly you aren't going to get anywhere. Palo Alto is a channel company; you need to find a channel partner that considers a one-off sale worth their time. Palo Alto does do direct deals, but not small ones.
Thanks, I think the cloud approach is the only way, I wanted to do it locally. For personal use, cloud providers are very hostile, especially if your use case is to do things that aren't normally done.
I've bought a Palo Alto Networks big blue box on eBay in the past.
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.
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).
Readit News
"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"
Deleted Comment
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).
[1]: https://applipedia.paloaltonetworks.com/
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.
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.
Deleted Comment
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...