03-08-2016 12:06 AM - edited 03-08-2016 12:07 AM
A customer has been warned about DROWN attack (https://drownattack.com/) on one of its servers. As a server is behind PA I thought there was no risk. But searching through signature database I didn't find anything about DROWN attack. I've also checked all CVEs connected with attack (CVE-2015-3197, CVE-2016-0703, CVE-2016-0800) and PA doesn't have signature for any of them!
Anyone knows about if PA covers this attack? Anyone contacted PA about this already?
03-08-2016 01:07 AM
Hi santonic,
This has been reported to support yes.
I'd recommend that you open a case with support to get information on the coverage.
Cheers,
-Kim.
03-08-2016 02:32 AM - edited 03-08-2016 02:32 AM
Hi Santonic,
My understanding is that this attack requires SSLv2 to be supported? (correct me If I am wrong) I think the worse security risk is to have a server that supports SSLv2, I know the PAN device does not support this, it doesn't even support v3. I know SSLv2 was removed from OpenSSL toolkit on the 15th feb this year with v1.1.0.
Ben
03-08-2016 03:19 AM
Yes, I agree. But one of the IPS functions is also to protect old or unpatched servers.
Customer was of course advised to upgrade the server.
03-10-2016 02:42 AM
From my understanding of this vulnerability, a signature to cover the weakness might be difficult to create.
Since the exploit collects data and then decrypts it, the vulnerability is not based in a protocol anomaly or an easily detectable exploit.
The collection of data based on cracking a 40-bit RSA key, and can be found over time against the realtive limited variations with 40-bit.
Data collection might be by interception between client and server, and this would be undetectable to both.
It might seem better to update the servers use of TLS/SSL, rather than wait for a usefull signature.
03-10-2016 06:42 AM
Would the PAN be able to detet this if it was performing reverse proxy ssl decryption?
Just a thought
03-10-2016 03:41 PM
Hi,
decryption would not really help, as Dulle explained intercepting communication over long time is sufficient to exploit this. Decryption can't help if someone is somewhere allowing (knowingly or unknowingly) copying of your traffic as it passes along the way.
03-10-2016 09:29 PM
And there came Application and Threat Content Release Notes Version 567, and proved me wrong....
03-15-2016 12:23 AM
Not really Dulle. The signature doesn't detect any exploit. It just detects use of SSLv2.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
