Information on Sweet32 for Palo Alto Networks Customers
Symptom
Summary of Sweet32
Security researchers at INRIA recently published a paper that describes how an attacker could levy an attack against information encrypted using older 64-bit block ciphers, such as 3DES and Blowfish to successfully recover plaintext. To be successful, the attacker would need to monitor a long-lived HTTPS session (the researcher’s proof of concept required a single 3DES HTTPS session be continuously monitored over two days) and be able to exploit a separate cross-site scripting vulnerability (XSS).
These attacks are not effective against modern encryption ciphers like AES and Elliptic Curve Digital Signature Algorithm (ECDSA).
We are not aware of any active attacks against this issue at this time.
Palo Alto Networks customers are only at risk in limited circumstances in the event of a “downgrade attack” which would force Palo Alto Networks systems to use 3DES as an encryption cipher of last resort. Customers who are concerned can prevent these “downgrade attacks” by implementing the workarounds outlined below.
Resolution
Impact on PAN-OS
Impact on SSL/TLS services on the firewall
PAN-OS system software supports 3DES block cipher as part of the cipher suite list negotiated over SSL/TLS connections terminating on the firewall. These sessions are IP layer 3 SSL services offered by the firewall, such as administrative web access for device management, GlobalProtect portals/gateways and captive portal. Similar to other web servers, PAN-OS maintains an internal cipher preference list. The 3DES cipher is not included in the top priority ciphers in the list since we consider it a weak cipher that will generally not be negotiated by the server. However, a malicious client can offer only the affected block ciphers as part of the client hello message forcing the server to negotiate 3DES.
Another aspect is the duration of the encrypted session that allows for a successful attack. The underlying assumption is that the same set of keys are used for the entirety of the connection.
How to secure SSL access
Palo Alto Networks customers can mitigate the Sweet32 attack by deploying ECDSA certificates and locking down the protocol version to TLSv1.2 for the various SSL/TLS services on the firewall. This ensures that an ECDSA-based cipher suite is negotiated by the server. The 3DES encryption algorithm are supported with RSA authentication. Setting an ECDSA certificate eliminates the possibility of negotiating the 3DES cipher.
Moreover, elliptic curve ciphers have a built in rekeying mechanism that would kick in sooner than the lifetime of the encrypted session, unlike RSA where rekeying can vary with specific SSL stack implementation. This ensures that a long-lived EC-based SSL session is not susceptible to the Sweet32 issue.
Steps for securing the SSL access:
- Generate/import an ECDSA server certificate on the firewall (If an ECDSA server certificate is already in place and being utilized, then this step can be skipped). IMPORTANT NOTE: If you are proceeding to create a certificate from the firewall for securing management interface access, make sure to create a CA certificate with 'ECDSA' first and then create a second 'ECDSA' child certificate signed by the first CA Certificate that was just created. Reference the second certificate in 'Step 3' instead of the initially created CA certificate. Using standalone ECDSA certificates (without a chain) will cause lose of management to the WebUI. For more information and resolution steps to this problem please see: Cannot login to the management interface using self-signed ECDSA certificate in SSL/TLS profile
- Create an SSL/TLS service profile with Min and Max versions set to TLSv1.2
- Reference the ECDSA child certificate in the service profile
- Apply the profile to the various L3 SSL/TLS services.
Below is a screen capture of SSL/TLS Service profile, this has to be be referenced in Device > Setup > Management > General Settings > SSL/TLS Service Profile to apply it to management interface. This restriction will be applicable to L3 interfaces with Interface Management profile with https enabled as well.
Impact on decrypted SSL traffic through the firewall
Palo Alto Networks customers who have deployed SSL decryption on the internet perimeter (Outbound) or in front of a data center server farm can secure their user population and/or corporate assets against a potential Sweet32 attack.
PAN-OS allows for cipher control on decrypted data traffic flowing through the firewall. The following steps can be used to prevent a potential Sweet32 attack on decrypted data traffic:
- Unselect the 3DES cipher in the Objects > Decryption Profile > SSL Protocol Settings > Encryption Algorithms
- Apply the decryption profile to your decryption policies
Below is a screen capture of the decryption profile that can be applied to Outbound and Inbound decryption policies:
Impact on SSH administrative CLI access
SSH tunnels are generally used for management access that carry less data at very low data rates. If an SSH connection would have a life size of 32GB or greater of data. An administrator can periodically reset the SSH keys for the management access via a simple expect or tcl script.
The following debug command can be used to reset the SSH keys (reboot required):
fwadmin@PA-200> debug system ssh-key-reset management
Impact on decrypted SSH access through the firewall
PAN-OS does not support DES/3DES ciphers while performing SSH proxy on management SSH sessions to secured assets behind the firewall. Such a traffic will not be affected by a potential Sweet32 attack.
Impact on IPSec and IKE
Palo Alto Networks next-generation firewalls are deployed in varied environments with a mix of devices supporting older and current IPSec crypto algorithms. PAN-OS supports DES and 3DES ciphers to maintain backward compatibility with such legacy systems and also support them as an IPSec peer.
PAN-OS provides a flexible way to configure each aspect of IKE and IPSec crypto. An administrator has to explicitly select encryption ciphers that need to be negotiated with the peer IKE gateway and IPSec tunnel end point.
This can be achieved by deselecting DES or 3DES algorithms in the IKE and IPSec crypto profile
Below is a snapshot of the crypto profiles that can be used to prevent a Sweet32 attack:
Note: For customers who do not want to remove DES and 3DES as part of phase 1 and phase 2 negotiation, PAN-OS reduces the chances of a potential Sweet32 attack as it rekeys the connection based on the data transferred.
An administrator can set the life size of an IPSec connection by setting the life size as 30GB (or by using a value below 32GB). Here is CLI command that can be used to achieve this:
fwadmin@PA-200# set network ike crypto-profiles ipsec-crypto-profiles corp-ike lifesize
> gb specify lifesize in gigabytes(GB)
> kb specify lifesize in kilobytes(KB)
> mb specify lifesize in megabytes(MB)
> tb specify lifesize in terabytes(TB)
<Enter> Finish input
Should you have any questions or need assistance with implementing the steps outlined above, please don’t hesitate to contact our support team at https://support.paloaltonetworks.com
Additional Information
Refer CVE-2016-2183 for more information.