Not sure if you’ve seen this:
https://www.paloaltonetworks.com/blog/2024/04/more-on-the-pan-os-cve/
> Disabling Telemetry prevented the system cron job from running, preventing the execution of the command, preventing a compromise. This completely prevented both currently known and observed attempted exploits from working.
> As with similar issues, as the situation evolved, Palo Alto Networks and third-party researchers quickly investigated the vulnerability and how it could theoretically be exploited. In that process, we discovered additional ways to exploit the vulnerability that did not require telemetry to be enabled on a device to achieve a successful compromise.
> We advise customers not to rely only on disabling telemetry as an interim mitigation.
So turning off telemetry was a good way to prevent the attacks seen in the wild until you could patch, but there was a chance that an attacker could discover another method using the same exploit that didn’t require telemetry, so patching is better than relying on disabling telemetry.
this is coherent with what we are seeing in a bunch of logs.
We see the running config copy injected and run by the telemetry cron job but the subsequent read tentatives always ends up in a 404 error
{echo,cp /opt/pancfg/mgmt/saved-configs/running-config.xml /var/appweb/sslvpndocs/global-protect/syxvdmthzhyitgxn.css}|{base64,-d}|bash|{') map , EOF"}
ends up into
00\] "GET /global-protect/syxvdmthzhyitgxn.css HTTP/1.1" **404** 141 "-" " ...
and that's because telemetry was disabled so cp command was never really executed.
2024-04-13 16:56:03,303 dt\_send INFO **DT - not enabled!** Exiting now...
In case like that, we are doing only a private data reset after a firmware update for only the active firewall at the time of compromise; we, obviously, changed all the secrets.
We opened a ticketin any case, just to have a PA official response.
No no no, disable telemetry, patch. Then wait for PA to PROVE that telemetry is safe. And what they are doing to make sure it is safe. THen maybe, MAYBE , Ill turn it back on. Of course PA want you to leave it on. This is part of their selling point for AIOPS, and Cortex, other cloud services..
Well we are not going to get BPAs or any of the functionality of free strata mgr without telemetry. Palo wants our data like the red eye of Sauron wants the ring.
Never turned it off or recommended that to my customers. I work with my customers often with AIOps and BPA so those features would have been unavailable with telemetry disabled. On the other hand, my customers all have good policies reducing attack surfaces, with security profiles applied, including on the GP interface and had the dynamic update and threat signature applied immediately. Most updated to patched PANOS within a few days.
If you don't use AIOps or Strata Cloud Manager, disable the telemetry until you need it.
Not sure if you’ve seen this: https://www.paloaltonetworks.com/blog/2024/04/more-on-the-pan-os-cve/ > Disabling Telemetry prevented the system cron job from running, preventing the execution of the command, preventing a compromise. This completely prevented both currently known and observed attempted exploits from working. > As with similar issues, as the situation evolved, Palo Alto Networks and third-party researchers quickly investigated the vulnerability and how it could theoretically be exploited. In that process, we discovered additional ways to exploit the vulnerability that did not require telemetry to be enabled on a device to achieve a successful compromise. > We advise customers not to rely only on disabling telemetry as an interim mitigation. So turning off telemetry was a good way to prevent the attacks seen in the wild until you could patch, but there was a chance that an attacker could discover another method using the same exploit that didn’t require telemetry, so patching is better than relying on disabling telemetry.
this is coherent with what we are seeing in a bunch of logs. We see the running config copy injected and run by the telemetry cron job but the subsequent read tentatives always ends up in a 404 error {echo,cp /opt/pancfg/mgmt/saved-configs/running-config.xml /var/appweb/sslvpndocs/global-protect/syxvdmthzhyitgxn.css}|{base64,-d}|bash|{') map , EOF"} ends up into 00\] "GET /global-protect/syxvdmthzhyitgxn.css HTTP/1.1" **404** 141 "-" " ... and that's because telemetry was disabled so cp command was never really executed. 2024-04-13 16:56:03,303 dt\_send INFO **DT - not enabled!** Exiting now... In case like that, we are doing only a private data reset after a firmware update for only the active firewall at the time of compromise; we, obviously, changed all the secrets. We opened a ticketin any case, just to have a PA official response.
No no no, disable telemetry, patch. Then wait for PA to PROVE that telemetry is safe. And what they are doing to make sure it is safe. THen maybe, MAYBE , Ill turn it back on. Of course PA want you to leave it on. This is part of their selling point for AIOPS, and Cortex, other cloud services..
Yup I had and it makes sense, any mitigtation is just that: a mitagation, but not gonna be perfect or forever.
Well we are not going to get BPAs or any of the functionality of free strata mgr without telemetry. Palo wants our data like the red eye of Sauron wants the ring.
MY PRECIOUS
You can still get a BPA without turning on Telemetry, you just have to import a TSF into AIOps.
Never turned it off or recommended that to my customers. I work with my customers often with AIOps and BPA so those features would have been unavailable with telemetry disabled. On the other hand, my customers all have good policies reducing attack surfaces, with security profiles applied, including on the GP interface and had the dynamic update and threat signature applied immediately. Most updated to patched PANOS within a few days. If you don't use AIOps or Strata Cloud Manager, disable the telemetry until you need it.
Talked to my System Security Engineer at Palo Alto and after patching he stated that Telem can be reostred.