PAN-OS Exposure to ROBOT Attack

[emoret]

Background

ROBOT [1] is an attack that affects the TLS RSA key exchange and could lead to decryption of captured sessions if the TLS server originally serving said captured session is still alive, vulnerable and using the same private key.

Exposure

SSL Decryption and GlobalProtect are susceptible to this issue. Our engineers are working on a software fix. We recommend customers running PAN-OS to upgrade to a fixed version of software or use content update 757, and implement further mitigations through the configuration changes described below under “Mitigations”. PAN-OS impacted releases include 6.1.19 and prior, 7.1.14 and prior, 8.0.6-h3 and prior.

Fix and Mitigations

Software update

PAN-OS 6.1.20 and newer, 7.1.15 and newer,  and 8.0.7 and newer are fixed. Customers exposed to this vulnerability are invited to upgrade to a corrected version of PAN-OS.

Content Update

Palo Alto Networks has released content update 757, which includes a vulnerability signature (“TLS Network Security Protocol Information Disclosure Vulnerability – ROBOT”, #38407) that can be used as an interim mitigation to protect PAN-OS devices until the software is upgraded. For complete protection, signature #38407 must be applied upstream from any interfaces implementing SSL Decryption, or hosting a GlobalProtect portal or a GlobalProtect gateway.

SSL Decryption Mitigation

Customers running PAN-OS 7.1 or later can configure their SSL Decryption profiles to disable RSA.

GlobalProtect Mitigation

If the GlobalProtect server certificate is using RSA, customers running PAN-OS 7.1 or later can opt to replace this certificate with one implementing the Eliptic Curve DSA algorithm as a safer alternative.

Note: A PAN-OS 7.1 known issue prevents properly formatted ECDSA CSR. As a result, the Global Protect ECDSA certificate could either be generated:

• on appliance by temporarily importing the enterprise Certificate Authority in PAN-OS; or
• on external enterprise PKI system then imported into PAN-OS along with its private key.

 

See Also

PAN-OS Technical Documentation

Critical Issues Addressed In PAN-OS Releases

Best Practices For PAN-OS Upgrade

Reference

[1] https://robotattack.org/

[vzit]

Hi, if we consider only inboud SSL inspection we know that PA works transparently and doesn't functioning as a proxy if RSA key exchange is used. Is right that we consider PA not vulnerable for ROBOT attack for inbound SSL inspection?

[emoret]

Inbound SSL Inspection processing is not actively taking part in the client to server communication, it merely uses the uploaded server's certificate to parallelly decrypt sessions destined to the end server. If the later is itself vulnerable to ROBOT, an attacker could mount an attack and decrypt a pre-captured TLS session. In that regard we could say that PAN-OS is not vulnerable to the ROBOT attack when inbound SSL inspection is configured.

[scottyfresh]

We generated an ECDSA cert on a PA3020 running PANOS 7.1.11 to mitigate the vulnerability found on a portal using an RSA certificate. The CSR did not check out clean - results show a signature algorithm of SHA1, therefore the certificate cannot be signed by a CA which requires a minimum of SHA256 for a signature on a ECDSA CSR. The mitigation below did not work. Will the maintenance release resolve this?

GlobalProtect Mitigation

If the GlobalProtect server certificate is using RSA, customers running PAN-OS 7.1 or later can opt to replace this certificate with one implementing the Eliptic Curve DSA algorithm as a safer alternative.

[emoret]

The article was just updated to include the PAN-OS 7.1 CSR known issue.

[vzit]

Hi to all. Seems that IPS signature (Unique Threat ID: 38407) doesn’t work if SSL inbound inspection is enabled.
You can see this link for better explanation: https://live.paloaltonetworks.com/t5/Threat-Vulnerability-Articles/SSL-Vulnerability-Non-Detection-B...
In other word, seems that we cannot protect inside network with IPS signature regarding SSL (handshake phase) if ssl inbound is configured.Is this confirmed also for you?

[emoret]

Signature 38407 needs to be applied upstream of the protected services as documented above. This applies to SSL/Decryption as well as GlobalProtect.

[scottyfresh]

Regarding the PanOS7.1 note, does this mean ECDSA certs have to be self-signed? Are we able to use a trusted CA?

Note: A PAN-OS 7.1 known issue prevents properly formatted Eliptic Curve DSA Certificates Signing Requests. As a result, such certificates have to be locally generated. If the required signing CA or Sub-CA is missing from PAN-OS, the firewall operator may need to import it to PAN-OS temporarily.

[vzit]

Hi Emoret. If you enable signature 38407 on upstream PA, the service are protected BUT if you also enable ssl inbloud inspection (on PA) and try a test for ROBOT attack you will see that the same service is not protected anymore even if signature is enable. This is what I can see from my lab

[scottyfresh]

@emoretDo you mean this CSR has to generated on an external system? 

Note: A PAN-OS 7.1 known issue prevents properly formatted Eliptic Curve DSA Certificates Signing Requests. As a result, such certificates have to be locally generated. If the required signing CA or Sub-CA is missing from PAN-OS, the firewall operator may need to import it to PAN-OS temporarily.

[scottyfresh]

Will the 7.1.15 maintenance release remediate the ROBOT finding on GlobalProtect portals using an RSA certificate? 

[emoret]

As documented in this article, PAN-OS 7.1.15 includes the fix for ROBOT.

[Dan-Bowen]

"signature #38407 must be applied upstream from any interfaces implementing SSL Decryption, or hosting a GlobalProtect portal or a GlobalProtect gateway."

How can you ensure IPS is applied on the Global Protect interface? There are no manual created security policies required for access to that AFIK? I can't even see access to the portal page in the traffic logs i.e. if I browse to the portal page from external and then check the logs filtering for that public IP there is nothing there. I can see actual VPN traffic in the logs.

Is IPS etc. just inherently on for Global Protect portal access?

[emoret]

@Dan-Bowen, to protect GP traffic you need to implement the policy on an upstream device. This could be a separate hardware platform or virtual machine running signature #38407. Traffic would first hit the upstream device, be sanitized then reach the separate downstream GP gateway.

[Dan-Bowen]

Ah I see. The GP portal/GW traffic is out of band of the threat protection services. Patching it is then!

Thanks for your speedy help.