Palo Alto Networks PAN-OS Zero-Day Exploitation(volexity.com)
volexity.com
Palo Alto Networks PAN-OS Zero-Day Exploitation
https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/
65 comments
[deleted]
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.
Isn't that just insecure???
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???
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).
[1]: https://applipedia.paloaltonetworks.com/
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/
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.
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 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.
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.
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.
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.
You nailed it. In my experience these "security" teams accumulate people who want PM level powers without having to deal with any of the accountability.
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.
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.
I get that this sort of MITM often breaks CI pipes, but working with this shouldn't be anything more than a chunk of work involving stuff you ought to be doing already, including:
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"
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"
Agreed, and that wasn't the problem.
I hate ZScaler with a passion.
At my last job, my CISO made the company trial ZScaler. When it caused tons of problems for Engineering, he cancelled the trial, then tried out CloudFlare's MitM proxy, which of course had the same problems.
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.
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.
Yeah, it needs to be rolled out and tested a lot. And not all traffic should be decrypted, namely banking and health.
> Isn't that just insecure???
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.
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.
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.
I've worked with PA firewalls for a while.
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 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.
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.
Companies have a legal and fiduciary duty wrt everything that goes on with their equipment and services.
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.
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 don't know" and "all employees require no-consent supervision" and Fusion Centers .. yes, you are right, we disagree
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…
Its typically used for detecting malware, detecting data loss prevention, or forensics. "Drive by crap like port scanning for sshd" isn't even relevant to why companies mitm SSL. And yes I see it detect but not stop active threats on a daily basis.
These tools typically claim to block or catch stupidly high number of threats per unit time. And they usually bucket the drive-by stuff as a threat to achieve this narrative. I agree it’s hogwash.
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.
https://honest.security
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.
https://honest.security
>I agree it’s hogwash.
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.
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.
You know what I mean, the TLS middleware is part of your IDS suite. Anyway.
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.
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.
These are more of an analyst tool for detection than blocking.
I run a MITM proxy for adblocking too, but haven't heard of any companies doing that with theirs.
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.
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.
I'm not saying no.
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.
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.
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.
Not the first widely exploited 0day in GlobalProtect. Can you really consider this a highly secure product?
https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
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.
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?
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.
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.
"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.
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.
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 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.
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.
Disable? This is the type of thing that enterprises make the conscious effort to pay for a higher tier license and enable.
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 primarily use it as a tool to aggregate logs, alerts, and to proactively audit configurations.
It's great at finding people who can't remember passwords or misbehaving services or software.
It's great at finding people who can't remember passwords or misbehaving services or software.
[deleted]
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.
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.
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.
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.
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.
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.
Just buy a lab unit from CDW. The American website annoyingly has a "call us" for pricing but a PA-440 is $979 CAD for comparison.
https://www.cdw.ca/product/palo-pa-440-security-appliance-la...
https://www.cdw.ca/product/palo-pa-440-security-appliance-la...
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).
Firmware patch should be available on the 14th
What does HN consider to be a good alternative VPN to GlobalProtect?
[deleted]
> Q. Has my device been compromised by this vulnerability?
> 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...
> 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...
You want them to share their IoC so the exploit authors can add to the exploit’s mitigations?
IoCs are always public
[deleted]
I'll stick to using a Linux firewall.
PaloAlto devices ARE “Linux Firewalls”
https://live.paloaltonetworks.com/t5/general-topics/how-to-a...
https://live.paloaltonetworks.com/t5/general-topics/how-to-a...
They aren't exactly linux firewalls, even if they run linux as management OS.
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
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
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.
"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"