Thousands of Palo Alto Networks Firewalls Compromised This Week After Critical Security Hole (theregister.com) 23
Palo Alto Networks boasts 70,000 customers in 150 countries, including 85% of the Fortune 500.
But this week "thousands of Palo Alto Networks firewalls were compromised by attackers exploiting two recently patched security bug," reports the Register: The intruders were able to deploy web-accessible backdoors to remotely control the equipment as well as cryptocurrency miners and other malware. Roughly 2,000 devices had been hijacked as of Wednesday — a day after Palo Alto Networks pushed a patch for the holes — according to Shadowserver and Onyphe. As of Thursday, the number of seemingly compromised devices had dropped to about 800. The vendor, however, continues to talk only of a "limited number" of exploited installations... The Register has asked for clarification, including how many compromised devices Palo Alto Networks is aware of, and will update this story if and when we hear back from the vendor.
Rumors started swirling last week about a critical security hole in Palo Alto Networks appliances that allowed remote unauthenticated attackers to execute arbitrary code on devices. Exploitation requires access to the PAN-OS management interface, either across the internet or via an internal network. The manufacturer did eventually admit that the firewall-busting vulnerability existed, and had been exploited as a zero-day — but it was still working on a patch. On Tuesday, PAN issued a fix, and at that time said there were actually two vulnerabilities. The first is a critical (9.3 CVSS) authentication bypass flaw tracked as CVE-2024-0012. The second, a medium-severity (6.9 CVSS) privilege escalation bug tracked as CVE-2024-9474. The two can be chained together to allow remote code execution (RCE) against the PAN-OS management interface... once the attackers break in, they are using this access to deploy web shells, Sliver implants, and/or crypto miners, according to Wiz threat researchers.
But this week "thousands of Palo Alto Networks firewalls were compromised by attackers exploiting two recently patched security bug," reports the Register: The intruders were able to deploy web-accessible backdoors to remotely control the equipment as well as cryptocurrency miners and other malware. Roughly 2,000 devices had been hijacked as of Wednesday — a day after Palo Alto Networks pushed a patch for the holes — according to Shadowserver and Onyphe. As of Thursday, the number of seemingly compromised devices had dropped to about 800. The vendor, however, continues to talk only of a "limited number" of exploited installations... The Register has asked for clarification, including how many compromised devices Palo Alto Networks is aware of, and will update this story if and when we hear back from the vendor.
Rumors started swirling last week about a critical security hole in Palo Alto Networks appliances that allowed remote unauthenticated attackers to execute arbitrary code on devices. Exploitation requires access to the PAN-OS management interface, either across the internet or via an internal network. The manufacturer did eventually admit that the firewall-busting vulnerability existed, and had been exploited as a zero-day — but it was still working on a patch. On Tuesday, PAN issued a fix, and at that time said there were actually two vulnerabilities. The first is a critical (9.3 CVSS) authentication bypass flaw tracked as CVE-2024-0012. The second, a medium-severity (6.9 CVSS) privilege escalation bug tracked as CVE-2024-9474. The two can be chained together to allow remote code execution (RCE) against the PAN-OS management interface... once the attackers break in, they are using this access to deploy web shells, Sliver implants, and/or crypto miners, according to Wiz threat researchers.
Re: (Score:2)
I guess as a POC, sorta like printing "You've been stoned" made sense.
I have been out of the enterprise scale firewall hardware game for a bit; but my assumption is the stateful nature of the IPv4/6 protocol itself and most of the L7 classification type work people use PAN devices for as opposed to much cheaper L3 devices that don't need expensive monthly subscriptions are tasks that have to be done with more traditional SISD fundamental compute units. Not really what you'd want for "mining" or are they put
Re: (Score:2)
Or perhaps they wanted to ensure that the firewalls got patched without being destructive.
Re: (Score:2)
It's almost like they are unethical white-hats. Which somehow sounds like a good thing. Now, it's also possible the summary just threw miners in there as some kind of recognizable malware for the uninformed. If so, then it's just another exploited vulnerability and a real bad one at that.
Re: (Score:2)
It's almost like they are unethical white-hats. Which somehow sounds like a good thing.
Perhaps it is, since this also tends to describe an internal red team comprised of the CISO staff and perhaps some insurance auditors.
(I can’t imagine trying to insure a network that large without validating risk first. In a very direct way.)
Security Company (Score:3)
I guess these days a 'security company' is a company that adds extra breaches into your network by adding shoddy code to the gateway points.
Re: (Score:2)
Sadly not exactly unique in this space:
Cisco PIX/ASA, Ivanti, Citrix, and Palo Alto (previously) have all had serious RCE vulns that were either unauthenticated or only required basic previliges like what would be assigned to every employee to connect to the vpn, use the captive webportal etc, in fairly recent memory.
If you get to look at the firmware to these things you find out they are often piles of decades old Perl and PHP scripts. You'd like think these things are built with more hardened stuff from s
Re: (Score:1)
Re: (Score:2)
Unfortunately, yes. Just look at one week of alerts for security problems with security components to see how bad things are.
Re: (Score:3)
Not just gateway points...
At this point most "security" offerings from third parties are risks. They demand administrative access to frequently redundantly do the things that the base platform already provide, which means the only outcome is larger attack surface.
They are not in the market by virtue of value, but by virtue of oblivious assumptions of brand value combined with sometimes downright underhanded sales tactics. I've heard people complain of 'security' vendors threatening to tell managers that t
Insecurity by using security elements (Score:3)
An all-too common problem these days. You do get the impression that makes of security elements like firewalls, IDS, SIEM, VPN endpoints, etc. do not know how to write code, and even less how to write secure code. Also see the Crowdstrike incident for one well analysed instance of abject failure. This state of affairs is utterly unacceptable and truly pathetic. We need vendor liability, at the very least for insecure security components. Of course, an OS is a security component in the broader sense, so some very powerful players are strictly opposed to being held responsible when they sell insecure crap.
That is not to say you should not use these things. Not using them likely still a lot worse. But you must be prepared to patch these components on short notice and you must not trust them. One reason why careful operations use two different firewalls from two vendors at their border.
Re: (Score:2)
To be fair to CrowdStrike, there's not much that's more secure than a system that won't even boot and get online. So.... mission accomplished?
I will go so far as to say you should not use a lot of these things. Many of them are now redundant with what comes with the platforms they are trying to secure. But at least be surgical, my corporate windows load has about 3 different anti-malware suites running concurrently, 4 different remote patch management solutions, and at least 2 different "security monitorin
A “limited number” (Score:2)
As we move toward the ever more complex (Score:3)
I think we're going to have to evolve security past what is the current ideal of (effectively) moats / strong doors to an even lower internal trust model. We simply can't afford to risk the moat's builder leaving an unintended bridge, or the door builder using a shoddy lock.
What will that entail? Well, if I knew I'd be ridiculously wealthy and buying my own G800.
Re: (Score:3)
In fairness, Palo Alto has been a leader in that space as has Cisco with ISE. They have done a lot around trying to do things like associate network flows with individual users and getting out of being edge devices and being able to do policy enforcement right inside the enterprise core. Always VPN and variations on 802.1x solutions etc even push that policy enforcement right down to the client.
They have gotten that hilariously wrong at times too - seen lots of reports where the credentials the device uses
Re: (Score:3)
I find "Zero Trust" to have taken a bit of a bad turn.
It started out well enough, acknowledging that the whole notion of a 'trusted internal network' is deeply flawed, and you need all services to assume that any client network could be as adversarial as a random internet access.
But it became "I can't let anything connect to me unless I have an agent running with root privilege on every possible client device". So, the owner of a network can't trust me unless I very much trust them. As a result, I have to
Yes, but... (Score:3)
This does look pretty rubbish - somehow you can log in across a network, even if you don't have credentials. Then you can somehow gain higher privileges from that login. This doesn't feel like "an unlucky bug", but rather is symptomatic of generally janky coding standards and equally janky testing.
The usual caveats apply though... there should be no way to access the login functionality remotely. Even those on the LAN ought to be on a particular segment of it, so of 8.2 billion people on earth, only about 20 ought to be able to mount such an attack. The fact that hundreds/thousands of devices can be attacked quite so quickly suggests thousands of shops aren't following decent security practices. As much as Palo Alto Networks look to be pretty sucky, there's no way they could protect people from their own poor standards.
Re: (Score:2)
In Cybersecurity, do not put all eggs in the same (Score:2)
We were affected by this. But it was painless: we use more than one firewall vendor, for this exact reason. Behind our PaloAlto firewalls we had another firewall from a different vendor, so no much harm was done other than a nuisance to swap a set of wires and ship the unit to PA for RMA and forensics.
Re: (Score:2)
We were affected by this. But it was painless: we use more than one firewall vendor, for this exact reason. Behind our PaloAlto firewalls we had another firewall from a different vendor, so no much harm was done other than a nuisance to swap a set of wires and ship the unit to PA for RMA and forensics.
Multiple firewall vendors means multiple training and support needs internally and/or multiple support contracts that also support a “swap a set of wires” level of enterprise support.
In other words, it’s only painless when you can afford it to be. The other 99% of the time I’d imagine the maintenance costs are a painful enough FUD budget fight no matter how justified. Kudos to who is succeeding for you in that endeavor. Not everyone works for competent management capable of respec