PAN-OS exposure to ROBOT attack

by emoret on ‎12-27-2017 11:56 AM - edited on ‎03-13-2018 12:09 PM by srichardson (21,373 Views)

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.

Screen Shot 2017-12-21 at 9.52.07 AM.png

 

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.

Screen Shot 2017-12-20 at 1.02.01 PM.png

 

Reference

[1] https://robotattack.org/

 

Comments
by vzit
on ‎01-04-2018 02:56 AM

 

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?

by emoret
on ‎01-04-2018 12:23 PM

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.

by scottyfresh
‎01-04-2018 03:04 PM - edited ‎01-04-2018 03:05 PM

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.

 

by emoret
on ‎01-04-2018 06:14 PM

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

by vzit
on ‎01-05-2018 01:31 AM

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?

by emoret
on ‎01-05-2018 11:26 AM

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

by scottyfresh
on ‎01-05-2018 11:35 AM

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.

by vzit
on ‎01-05-2018 11:47 AM

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

 

by scottyfresh
on ‎01-05-2018 11:51 AM

@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.

 

by scottyfresh
on ‎01-18-2018 10:29 AM

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

by emoret
on ‎01-18-2018 10:32 AM

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

by Dan-Bowen
on ‎01-24-2018 02:41 PM

"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?

by emoret
on ‎01-24-2018 02:57 PM

@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.

by Dan-Bowen
on ‎01-24-2018 03:00 PM

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.

Ignite 2018, Amsterdam, Netherlands
Ask Questions Get Answers Join the Live Community