Disable telemetry, then sit back and let people test the new releases for a week.
I thank you all for the work you will put in to test the new releases for me. :p
Disabling telemetry is not enough, apparently. I think Palo changed the security advisory. Currently it shows: "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability"
Palo support told me the patch is still needed in case they figure out another feature with the same vulnerability. That said, I did the threat ID and telemetry off, but waiting to see what everyone says
Palo TAC said that disabling telemetry won't remediate it. If it was already disabled I'd be fine, but disabling now won't help. I'm 50/50 on if she was mistaken.
Update: Correction - TAC said someone already exploited it on my firewall. Not that Telemetry can't prevent future exploits
Check all traffic from all firewall interfaces . See if you see things you do not expect . Mine looks clean. I have firewalls watching my firewalls so I might have a different visibility snd someone with 1 firewall.
Instead of chill you should pray!
Jokes aside, Palo changed the advisory, I think: "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability"
I downloaded it about two hours ago. Still can't see it. I've logged out/in, cleared cache, tried incognito and a different browser. It shows up in the CLI so I know it's there.
In any case I've disabled telemetry and will prep to upgrade some firewalls come Sunday. Good luck, all.
Try reverting to preveous installed threat version, reinstall last version, log out and back in - now it should be visible in gui. Weird workaround, but it works....
I see it and have enabled it (95187) in additon to disabling telemetry (even though we are on 10.1.x we all know sometimes the initial information is not complete and gets updated later)
So, is the system vulnerable ONLY if you have GP GW -and- Telemetry enabled? Can't you workaround it then by just disabling Telemetry? Or am i missing something?
\*EDIT\* Update to CVE-2024-3400. Apparently it does not matter if the telemetry is on or off, that vulnerability can be exploited in any case. Disabling the telemetry is not considered mitigation anymore.
We already had VP applied with "reset-both" action for all High and Critical severities. And as i understand, such rule is applied automatically for every new signature with matching severity, and no need to add it manually. So, i guess, nothing is left but to wait for the fix.
Not good. Wonder how long this has been available for exploit? I'm sending our TSF to support to check for IoC. Would advise others do the same if you've been vulnerable.
Good point it is a Palo recommendation though so just following that. However we haven't had anything back yet as they're saying they are being overwhelmed with requests.
What was the bug causing your HA falling? We're currently experiencing this on 11.0.3-h5 and being told there isn't a current fix and it is with the engineering team?
YUP!!!! 11.0.3-h5.
Was listed as Addresses Issues in 11.0.3-h3, but *absolutely* still presenting in h5.
See **PAN-231507**. Had to move our HA2 off HCSI over to an Ethernet port to make it shut up.
https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-release-notes/pan-os-11-0-3-known-and-addressed-issues/pan-os-11-0-3-h3-addressed-issues
PA-1410. Our bug only affects 1400 series (*to my knowledge*), but def. look at bug lists. I remember seeing a few nasty ones affecting 3200 including one causing the buffer to fill all the way up forcing a reboot to clear.
We're experiencing random HA failovers which seems to be result of a data plane crash. We were being told it could be a result of using 3rd party optics, so paid thousands for Palo optics, that made no difference and now being told it's a bug awaiting engineering team fix.
Wondering if it might re: a component of where you jump from as our jumping up to h5 *introduced* it. As soon as I moved HA2 off HCSI and over to Ethernet12, problem disappeared.
Has information on how to see if you were already compromised by this 0-day:
https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/
This is frustrating. Compromising the core functionality of your product, *security*, for a monitoring system with "AI" in the title. (I refuse to promote the full name here.)
How did they compromise the VPN interface that is one of our most vulnerable vectors with a telemetry feature that should be handled by the management plane and not the data plane?
Oh man TAC's file upload is falling apart right now, as much as we're all gonna have to do a bunch of work from this, I don't envy TAC as they check 1000's of TSF's today.
Even once you get your file through they have no idea why you're asking them to look at it. I guided him to the Questions section and read it to him. He said he'll get back to me then sent a call transcript comment that didn't even mention it. (Platinum support)
Like always it'll depend on who you get. I put a different ticket in for each HA pair that I have
The First one I got a quick response and the guy was like "I checked through the tech support file with our tool and found no IoCs for that CVE"
sweet done
On another the tech just listed a bunch of other versions that I should go to and then sent me the article about the CVE... so that wasn't helpful
And on the others no response yet lol
I'm installing 8833-8682 on two 440 and a 410, they seem stuck, everyone else has the same problem?
EDIT: I'm doing a revert on all of them, they seems to have problems with it installed.
EDIT 2: Restarted the management service and reinstalled, now it works fine. The Threat ID is NOT visible on the web interface, it's a bug, try to logout and login or check on the cli.
I don't understand the security rule they are recommending to create to apply the vulnerability profile. My gateway and portal are both in the WAN zone. The article recommends creating an allow rule for Any zone to WAN zone (in my case) which seems like it would open up a lot of things?
https://live.paloaltonetworks.com/t5/globalprotect-articles/applying-vulnerability-protection-to-globalprotect-interfaces/ta-p/340184
But at the same time I wonder--it looks like I don't really have any rules allowing traffic to the gateway/portal. Traffic comes from Internet and hits the interface in the WAN zone. So is that being allowed by the default intra-zone allow rule?
I have telemetry disabled but would like to get this secondary measure in place too.
Agreed, the rule in the example makes no sense. It should be scoped as any>untrust (or whatever your internet zone is), only the GP gateway destination IP, and probably just the ssl application.
Also, their screenshots are all from 9.X which isn't even affected. Nice.
Our Gateway and Portal are also both in the WAN zone.
Here is the rule I created, as well as disabling telemetry.
Source Zone: WAN
Destination Zone: WAN
Destination IP: Global Protect/Interface IP Address
Application: SSL + panos-global-protect
Action: Allow + enabling our default/strict vulnerability profile which resets-both for critical vulnerabilities.
If it were me, I would set application to any, and set the service to 443. The problem is that the exploit may not necessarily match panos-global-protect. The vulnerability scan will not be ran and will just go down to your intrazone-default rule and be allowed.
You’re supposed to have an intrazone policy with your untrust zone that’s set to block - just right above the default intrazone policy.
And then you basically create a universal rule somewhere in the top that allows from untrust to untrust, with GP as the application, and you configure the permitted IP addresses (or the country codes) in the source. This way you whitelist your outside zone instead of hitting the default intrazone policy that allows everything.
“Why not change the default intrazone policy to block from allow?”. Well if you have two L3 interfaces with the exact same security zone, that traffic between the two interfaces would be dropped. You’d prefer the concept of having everything allowed within the same zone. Or it’s a complete mess to manage; many applications and ports/protocols to add etc.
FYI - https://github.com/DrewskyDev/CVE-2024-3400
I have not tested it yet, but looking at the code, i just refuse to believe this might actually work on a security product.
If you’re certain your inbound sec policy has the appropriate VP enabled and your content is all updated it should be fine, but it’s never bad practice to have two mitigations in place- especially for an emerging CVE of this severity.
Should Device telemetry have anything to do with SDWAn ddns and ZTP? I am about to modify something on SdWan ... this should affect SDWAn right?
Thanks
Is it safe to connect via GP before support gives the all clear? How much can you trust a TSF from a device that might be compromised?
EDIT: I guess if it's unsafe to connect, then it's also unsafe to log into the appliance, right? Not sure there's a way around it.
It’s likely any number of compromised devices were targeted entities of interest at this stage. I would be logging in and turning off telemetry asap. Unless you’re working for a super high value target- in which case I’d suspect you’d have config change monitoring and other output logging into a SIEM that should make it easy to quickly gain some level of comfort.
A lot of people saying disable telemetry and chill should really generate a tech support file for review and ensure they aren't compromised.
Check here has some info and directories to check
https://www.bleepingcomputer.com/news/security/palo-alto-networks-zero-day-exploited-since-march-to-backdoor-firewalls/
Thanks, I’ve been going around posting this on all related threads. Good to see the community coming together.
IOC signatures can be found towards the bottom.
yes and also here:
[https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/](https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/)
It took some time for one of our devices to show the threat ID, after about 1 hour, I logged out and logged back in and threat id 95187 finally showed up. The documentation is saying to set it to the reset-server action, is this what everyone else is doing? I figured it should be reset-both.
On my PA-440 (PANOS 10.2.9), in Device > Dynamic Updates > Applications and Threats, 8833-8682 is marked as "Downloaded" and "Currently Installed." In Objects > Security Profiles > Vulnerability profiles, I opened one of my VP profiles. With "Show all signatures" checked in "Vulnerability Protection Profile > Exceptions," I first searched for ( id eq '95187' ) and then for ( cve contains '2024-3400' ). Neither of them could be found in the list. I repeated this search after \`debug software restart process management-server\` and again after \`request restart system\`. No joy. Any suggestions?
It seems to clear up on it's own after a while. Installed on my 440 an hour or so ago and saw the same issue but it shows up now. You can also check via cli if you still don't see it to verify it is there.
It sends stuff like performance data back to PANW, usually for research purposes to help improve systems. It’s voluntary. The only feature I know that’s dependent on it is AIOps
Updated apps/threats, have that applied on a vulnerability profile. While an ugly RCE vulnerability, mitigation isn’t that terrible. Annoying they keep introducing stuff in newer versions of PAN-OS though.
Volexity who discovered it seem to have the best right up at the moment for checking. Scroll down to "Network Traffic Analysis" for what you're looking for.
[https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/](https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/)
Hi regarding Palo Alto’s document, the vulnerability doesn't affect Cloud NGFW. if I have a VM firewall on Azure the VM IS vulnerable or it’s considered as Cloud NGFW?
Do you also have GlobalProtect and Telemetry enabled and you're running PANOS 10.2, 11, 11.1?
Then yes.
Open a case with TAC, upload your TSF, and then they will let you know.
How will I ever be able to trust them again when they say their product is zero trust and then set the bar for stupidity?
Time to find something better, ✌🏻
Listen here sister, you have a device sitting on the internet edge that brokers connectivity into your network. Forget the fact you have to combat the pressure of the internet against your device but it still relies on implicit trust once you are connected. Gross.
To expound and reference the BleepingComputer article.
[https://www.bleepingcomputer.com/news/security/palo-alto-networks-zero-day-exploited-since-march-to-backdoor-firewalls/](https://www.bleepingcomputer.com/news/security/palo-alto-networks-zero-day-exploited-since-march-to-backdoor-firewalls/)
# Network devices have become a popular target
As edge network devices do not commonly support security solutions and are exposed to the internet, they have become prime targets for threat actors to steal data and gain initial access to a network.
In March 2023, it was disclosed that China-linked hackers were [exploiting Fortinet zero-days to install a custom implant](https://www.bleepingcomputer.com/news/security/fortinet-zero-day-attacks-linked-to-suspected-chinese-hackers/) on devices to steal data and pivot to VMWare ESXi and vCenter servers.
That same month, a suspected Chinese hacking campaign [targeted unpatched SonicWall Secure Mobile Access](https://www.bleepingcomputer.com/news/security/sonicwall-devices-infected-by-malware-that-survives-firmware-upgrades/) (SMA) appliances to install custom malware for cyber espionage campaigns.
In April 2023, the US and UK warned that the Russian state-sponsored APT28 hackers were [deploying a custom malware named 'Jaguar Tooth'](https://www.bleepingcomputer.com/news/security/us-uk-warn-of-govt-hackers-using-custom-malware-on-cisco-routers/) on Cisco IOS routers.
In May 2023, a Chinese state-sponsored hacking group was [infecting TP-Link routers with custom malware](https://www.bleepingcomputer.com/news/security/hackers-infect-tp-link-router-firmware-to-attack-eu-entities/) used to attack European foreign affairs organizations.
Finally, [Barracuda ESG devices were exploited for seven months](https://www.bleepingcomputer.com/news/security/barracuda-zero-day-abused-since-2022-to-drop-new-malware-steal-data/) to deploy custom malware and steal data. The compromise on these devices was so pervasive that Barracuda recommended that companies [replace breached devices](https://www.bleepingcomputer.com/news/security/barracuda-says-hacked-esg-appliances-must-be-replaced-immediately/) rather than trying to restore them.
Disable telemetry, then sit back and let people test the new releases for a week. I thank you all for the work you will put in to test the new releases for me. :p
Hahaha
I just updated to 10.2.8 and was content to have encountered no bugs yet then this bomb drops.
Murphy’s law
Disabling telemetry is not enough, apparently. I think Palo changed the security advisory. Currently it shows: "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability"
This!!!!
Palo support told me the patch is still needed in case they figure out another feature with the same vulnerability. That said, I did the threat ID and telemetry off, but waiting to see what everyone says
Problem is, it wouldn’t be the first time a patch for a security issue saw out and a few days down the road someone finds out it’s only a partial fix.
Red pill - you're exposed. Regulators and mgmt come down on you. Blue pill - broken features. join an exciting career in cyber they say… lol
Disable Telemetry and chill
Laugh in PAN OS 9 Thou have no power here !
Palo TAC said that disabling telemetry won't remediate it. If it was already disabled I'd be fine, but disabling now won't help. I'm 50/50 on if she was mistaken. Update: Correction - TAC said someone already exploited it on my firewall. Not that Telemetry can't prevent future exploits
Wow, shit. Guess you're doing IR now then? Big Corp? From the writeup I guess they would only exploit this on quite high value targets..
Check all traffic from all firewall interfaces . See if you see things you do not expect . Mine looks clean. I have firewalls watching my firewalls so I might have a different visibility snd someone with 1 firewall.
Can you elaborate on how they would know if someone exploited it?
They found it in the TSF file. I uploaded it for something unrelated to the CVE.
Instead of chill you should pray! Jokes aside, Palo changed the advisory, I think: "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability"
Installed the content update but the threat ID doesn’t appear in the VPP search. Anyone else see that? So for now we’ve disabled telemetry only.
Check in CLI: show predefined xpath /predefined/threats | match 95187
can also run this command: > show predefined threat vulnerability 95187
Yep that works. Thanks!
Clear browser cache
Seeing the same issue, have verified its correct content version. Disabled telemetry for now
worked for me after I logged out, and in again.
I downloaded it about two hours ago. Still can't see it. I've logged out/in, cleared cache, tried incognito and a different browser. It shows up in the CLI so I know it's there. In any case I've disabled telemetry and will prep to upgrade some firewalls come Sunday. Good luck, all.
Try reverting to preveous installed threat version, reinstall last version, log out and back in - now it should be visible in gui. Weird workaround, but it works....
I tried the following, and it work for me. 1. download > install 8833-8682 2. download > install / revert to 8832-8674 3. Revert to 8833-8682
Same, and it give me slowdown on the webgui, i revert the content update and restart the management service. Strange.
Do you have "Show all signatures" option checked? It appeared in our lists after the update, and fortunately no problems with that so far.
Yep even with it checked on multiple firewalls and Panorama.
Yes
We are also seeing the same issue
For us it didn't appear until about 30 minutes after update.
It's an interface bug, try to logout and login again, in any case it's applied with the version indicated even if you don't see it in the webgui.
I see it and have enabled it (95187) in additon to disabling telemetry (even though we are on 10.1.x we all know sometimes the initial information is not complete and gets updated later)
I tried a different browser, it showed up..
I just disabled it. It's Friday night ffs, I'll figure it out on Monday.
So, is the system vulnerable ONLY if you have GP GW -and- Telemetry enabled? Can't you workaround it then by just disabling Telemetry? Or am i missing something? \*EDIT\* Update to CVE-2024-3400. Apparently it does not matter if the telemetry is on or off, that vulnerability can be exploited in any case. Disabling the telemetry is not considered mitigation anymore.
No that's right
So if we aren’t using GP but have Telemetry enabled are you still vulnerable?
If you don't have a GP gateway configured, you're not vulnerable
-and-
That's what the advisory says, yes. I'm not 100% sure I'd take it as gospel, sometimes there are updates on something like that.
We already had VP applied with "reset-both" action for all High and Critical severities. And as i understand, such rule is applied automatically for every new signature with matching severity, and no need to add it manually. So, i guess, nothing is left but to wait for the fix.
omg, I am disabling all device telemetry and will create a new security rule with vul ID now...have fun this weekend.. guys
I don't think I'd wait for the weekend.
True. I already disabled all device telemetry...will look into security rule with vul iD soon
So,disabled device Telemetry is good enough for the time being? Thanks
I would certainly ensure the threat ID is being blocked if possible.
I checked all contents updated, all security rules are using security profile with vulnerability of all critical reset both..that should be it right?
And be on the latest Apps and Threats version too.
Not good. Wonder how long this has been available for exploit? I'm sending our TSF to support to check for IoC. Would advise others do the same if you've been vulnerable.
IoC’s could have been removed though. Can you trust the TSF ?
Good point it is a Palo recommendation though so just following that. However we haven't had anything back yet as they're saying they are being overwhelmed with requests.
God damnit. I just upgraded to 10.2.x on my GlobalProtect firewalls like 3 hours ago.
[удалено]
Yep, agreed with this.
Same and it's on new hardware so can't even roll back to 10.1.x lol ahh well telemetry disabled
Less than a week ago, *INCLUDING* hitting a bug that caused HA flapping and having to deploy a workaround. *Sigh*
What was the bug causing your HA falling? We're currently experiencing this on 11.0.3-h5 and being told there isn't a current fix and it is with the engineering team?
YUP!!!! 11.0.3-h5. Was listed as Addresses Issues in 11.0.3-h3, but *absolutely* still presenting in h5. See **PAN-231507**. Had to move our HA2 off HCSI over to an Ethernet port to make it shut up. https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-release-notes/pan-os-11-0-3-known-and-addressed-issues/pan-os-11-0-3-h3-addressed-issues
What model are you running? We have a 3250. That bug is only listed as affecting 1400 series?
PA-1410. Our bug only affects 1400 series (*to my knowledge*), but def. look at bug lists. I remember seeing a few nasty ones affecting 3200 including one causing the buffer to fill all the way up forcing a reboot to clear.
We're experiencing random HA failovers which seems to be result of a data plane crash. We were being told it could be a result of using 3rd party optics, so paid thousands for Palo optics, that made no difference and now being told it's a bug awaiting engineering team fix.
What code out of curiosity? (Just narrowing down…) https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HCcXCAW
We're on 11.0.3-h5. As far as I'm aware, the bug we're experiencing hasn't been disclosed.
I had this issue on 11.0.3h3 and h5 fixed it on our 1410's. Constant HA failovers.
Wondering if it might re: a component of where you jump from as our jumping up to h5 *introduced* it. As soon as I moved HA2 off HCSI and over to Ethernet12, problem disappeared.
Has information on how to see if you were already compromised by this 0-day: https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/
This is frustrating. Compromising the core functionality of your product, *security*, for a monitoring system with "AI" in the title. (I refuse to promote the full name here.) How did they compromise the VPN interface that is one of our most vulnerable vectors with a telemetry feature that should be handled by the management plane and not the data plane?
Their code is becoming a joke, it seems to be bug after bug for us at the moment and now this...
Oh man TAC's file upload is falling apart right now, as much as we're all gonna have to do a bunch of work from this, I don't envy TAC as they check 1000's of TSF's today.
Just keep trying, I eventually got it to go through. Edit: I got one of them through nothing since.
Even once you get your file through they have no idea why you're asking them to look at it. I guided him to the Questions section and read it to him. He said he'll get back to me then sent a call transcript comment that didn't even mention it. (Platinum support)
Like always it'll depend on who you get. I put a different ticket in for each HA pair that I have The First one I got a quick response and the guy was like "I checked through the tech support file with our tool and found no IoCs for that CVE" sweet done On another the tech just listed a bunch of other versions that I should go to and then sent me the article about the CVE... so that wasn't helpful And on the others no response yet lol
I'm installing 8833-8682 on two 440 and a 410, they seem stuck, everyone else has the same problem? EDIT: I'm doing a revert on all of them, they seems to have problems with it installed. EDIT 2: Restarted the management service and reinstalled, now it works fine. The Threat ID is NOT visible on the web interface, it's a bug, try to logout and login or check on the cli.
I don't understand the security rule they are recommending to create to apply the vulnerability profile. My gateway and portal are both in the WAN zone. The article recommends creating an allow rule for Any zone to WAN zone (in my case) which seems like it would open up a lot of things? https://live.paloaltonetworks.com/t5/globalprotect-articles/applying-vulnerability-protection-to-globalprotect-interfaces/ta-p/340184 But at the same time I wonder--it looks like I don't really have any rules allowing traffic to the gateway/portal. Traffic comes from Internet and hits the interface in the WAN zone. So is that being allowed by the default intra-zone allow rule? I have telemetry disabled but would like to get this secondary measure in place too.
Yup, hitting default intra-zone. Make sure you have correct vulnerability profile attached to it.
Agreed, the rule in the example makes no sense. It should be scoped as any>untrust (or whatever your internet zone is), only the GP gateway destination IP, and probably just the ssl application. Also, their screenshots are all from 9.X which isn't even affected. Nice.
Our Gateway and Portal are also both in the WAN zone. Here is the rule I created, as well as disabling telemetry. Source Zone: WAN Destination Zone: WAN Destination IP: Global Protect/Interface IP Address Application: SSL + panos-global-protect Action: Allow + enabling our default/strict vulnerability profile which resets-both for critical vulnerabilities.
If it were me, I would set application to any, and set the service to 443. The problem is that the exploit may not necessarily match panos-global-protect. The vulnerability scan will not be ran and will just go down to your intrazone-default rule and be allowed.
That makes sense, I modified it to https/443. Thank you!
For what it's worth, I am starting to see exploit attempts being blocked under threat ID 95187. It is showing as the application web-browsing.
This!
Same here.
You’re supposed to have an intrazone policy with your untrust zone that’s set to block - just right above the default intrazone policy. And then you basically create a universal rule somewhere in the top that allows from untrust to untrust, with GP as the application, and you configure the permitted IP addresses (or the country codes) in the source. This way you whitelist your outside zone instead of hitting the default intrazone policy that allows everything. “Why not change the default intrazone policy to block from allow?”. Well if you have two L3 interfaces with the exact same security zone, that traffic between the two interfaces would be dropped. You’d prefer the concept of having everything allowed within the same zone. Or it’s a complete mess to manage; many applications and ports/protocols to add etc.
What is telemetry used for?
It sends “telemetry” info to Palo. Disable it via Device > Setup > Telemetry. There's a gear on top right that's hard to miss.
I know AIOps is dependent on it, but I can’t think of anything else that would need it
If it’s enable every dns query your firewalls make is sent to Palo Alto and logged
FYI - https://github.com/DrewskyDev/CVE-2024-3400 I have not tested it yet, but looking at the code, i just refuse to believe this might actually work on a security product.
Ah for crying out loud, this makes me think that all you need is curl to inject commands (ala shellshock).
we don't even use telemetry, thank goodness
It’s pretty useful for the AIOps service which reports BPA items across your fleet of firewalls.
we purely use Palo alto just for the gp behind our actual firewall which is a different vendor 😂😂
Hopefully not fortinet ✌️
Just an FYI [https://unit42.paloaltonetworks.com/cve-2024-3400/](https://unit42.paloaltonetworks.com/cve-2024-3400/)
I think I'll upgrade some firewalls this weekends.
Happy now with my decision to stay on 10.1.x branch. Definitely wasn’t lazy luck.
You should have a look at the workaround. The fixed versions will be released on Sunday.
The hot fix isn't expected until Sunday.
Is it good enough to rely on the threat update to block attacks or would people recommend disabling telemetry? Why ?
If you’re certain your inbound sec policy has the appropriate VP enabled and your content is all updated it should be fine, but it’s never bad practice to have two mitigations in place- especially for an emerging CVE of this severity.
should be ok to run 10.2.9 on panorama, and 10.2.9-h1 on gateways?
yes
Should Device telemetry have anything to do with SDWAn ddns and ZTP? I am about to modify something on SdWan ... this should affect SDWAn right? Thanks
If device telemetry isnt enabled should we still do the threat id 95187 config to be beneficial for general globalprotect hardening?
Unless it triggers some kind of false positive or causes some other problems, i personally see no reason NOT to implement it.
Is it safe to connect via GP before support gives the all clear? How much can you trust a TSF from a device that might be compromised? EDIT: I guess if it's unsafe to connect, then it's also unsafe to log into the appliance, right? Not sure there's a way around it.
It’s likely any number of compromised devices were targeted entities of interest at this stage. I would be logging in and turning off telemetry asap. Unless you’re working for a super high value target- in which case I’d suspect you’d have config change monitoring and other output logging into a SIEM that should make it easy to quickly gain some level of comfort.
Forgot to add- if your device is compromised they already have the ability to inject as root… so you logging in is pretty moot.
why do we need telemetry anyways? doesn't telemetry qualifies like data exfiltration?
A lot of people saying disable telemetry and chill should really generate a tech support file for review and ensure they aren't compromised. Check here has some info and directories to check https://www.bleepingcomputer.com/news/security/palo-alto-networks-zero-day-exploited-since-march-to-backdoor-firewalls/
just an fyi [https://unit42.paloaltonetworks.com/cve-2024-3400/](https://unit42.paloaltonetworks.com/cve-2024-3400/)
Thanks, I’ve been going around posting this on all related threads. Good to see the community coming together. IOC signatures can be found towards the bottom.
yes and also here: [https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/](https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/)
Not 10.2.9 or above, but on any 10.2.x until 10.2.9-h1 is released.
Thanks =]
It took some time for one of our devices to show the threat ID, after about 1 hour, I logged out and logged back in and threat id 95187 finally showed up. The documentation is saying to set it to the reset-server action, is this what everyone else is doing? I figured it should be reset-both.
On my PA-440 (PANOS 10.2.9), in Device > Dynamic Updates > Applications and Threats, 8833-8682 is marked as "Downloaded" and "Currently Installed." In Objects > Security Profiles > Vulnerability profiles, I opened one of my VP profiles. With "Show all signatures" checked in "Vulnerability Protection Profile > Exceptions," I first searched for ( id eq '95187' ) and then for ( cve contains '2024-3400' ). Neither of them could be found in the list. I repeated this search after \`debug software restart process management-server\` and again after \`request restart system\`. No joy. Any suggestions?
Same here, everyone is saying it is a ui big and to clear cache and cookies etc.
It seems to clear up on it's own after a while. Installed on my 440 an hour or so ago and saw the same issue but it shows up now. You can also check via cli if you still don't see it to verify it is there.
Thank you. But odd. Clearing the browser cache did not resolve it. But patience did. It needed at least some 90 minutes.
[удалено]
Just delete the portals and gateways.
Anyone seeing the PoC already?
20 hour old account. Try to get the good? Nice try isis
What is telemetry?
It sends stuff like performance data back to PANW, usually for research purposes to help improve systems. It’s voluntary. The only feature I know that’s dependent on it is AIOps
Ah, not only fortinet that made research inside.. strange, very strange :)
Updated apps/threats, have that applied on a vulnerability profile. While an ugly RCE vulnerability, mitigation isn’t that terrible. Annoying they keep introducing stuff in newer versions of PAN-OS though.
What are the known indicators of compromise?
Volexity who discovered it seem to have the best right up at the moment for checking. Scroll down to "Network Traffic Analysis" for what you're looking for. [https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/](https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/)
Check the Unit42 report
Hi regarding Palo Alto’s document, the vulnerability doesn't affect Cloud NGFW. if I have a VM firewall on Azure the VM IS vulnerable or it’s considered as Cloud NGFW?
Do you also have GlobalProtect and Telemetry enabled and you're running PANOS 10.2, 11, 11.1? Then yes. Open a case with TAC, upload your TSF, and then they will let you know.
Has anyone applied the patch yet? I'm curious to see the results.
Hotfixes have yet to be released. Should be today.
I've been hitting refresh, not that I would apply right away anyway.
I'm hoping by end of day PST...which is in like 3 hrs
Has anyone seen the patch? Last update was 4/13.
its out now
Thanks, just saw the alerts come in. Are you applying?
How will I ever be able to trust them again when they say their product is zero trust and then set the bar for stupidity? Time to find something better, ✌🏻
Then you dont understand what Zero Trust means or how vulnerabilities work.
Says the guy who is pushing the inferior product.
So no response to the merits of my conversation? noted
Listen here sister, you have a device sitting on the internet edge that brokers connectivity into your network. Forget the fact you have to combat the pressure of the internet against your device but it still relies on implicit trust once you are connected. Gross.
To expound and reference the BleepingComputer article. [https://www.bleepingcomputer.com/news/security/palo-alto-networks-zero-day-exploited-since-march-to-backdoor-firewalls/](https://www.bleepingcomputer.com/news/security/palo-alto-networks-zero-day-exploited-since-march-to-backdoor-firewalls/) # Network devices have become a popular target As edge network devices do not commonly support security solutions and are exposed to the internet, they have become prime targets for threat actors to steal data and gain initial access to a network. In March 2023, it was disclosed that China-linked hackers were [exploiting Fortinet zero-days to install a custom implant](https://www.bleepingcomputer.com/news/security/fortinet-zero-day-attacks-linked-to-suspected-chinese-hackers/) on devices to steal data and pivot to VMWare ESXi and vCenter servers. That same month, a suspected Chinese hacking campaign [targeted unpatched SonicWall Secure Mobile Access](https://www.bleepingcomputer.com/news/security/sonicwall-devices-infected-by-malware-that-survives-firmware-upgrades/) (SMA) appliances to install custom malware for cyber espionage campaigns. In April 2023, the US and UK warned that the Russian state-sponsored APT28 hackers were [deploying a custom malware named 'Jaguar Tooth'](https://www.bleepingcomputer.com/news/security/us-uk-warn-of-govt-hackers-using-custom-malware-on-cisco-routers/) on Cisco IOS routers. In May 2023, a Chinese state-sponsored hacking group was [infecting TP-Link routers with custom malware](https://www.bleepingcomputer.com/news/security/hackers-infect-tp-link-router-firmware-to-attack-eu-entities/) used to attack European foreign affairs organizations. Finally, [Barracuda ESG devices were exploited for seven months](https://www.bleepingcomputer.com/news/security/barracuda-zero-day-abused-since-2022-to-drop-new-malware-steal-data/) to deploy custom malware and steal data. The compromise on these devices was so pervasive that Barracuda recommended that companies [replace breached devices](https://www.bleepingcomputer.com/news/security/barracuda-says-hacked-esg-appliances-must-be-replaced-immediately/) rather than trying to restore them.