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.
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.
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:
Below is a screen capture for securing the web interface admin access of 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:
Below is a screen capture of the decryption profile that can be applied to Outbound and Inbound decryption policies:
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:
fwadmin@PA-200> debug system ssh-key-reset management
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.
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.
The Palo Alto Networks Support Team
