BREACH vulnerability - CVE 2013-3587

[vpswing]

We run 4 cPanel servers (latest stable release). The latest PCI-DSS scan failed because of CVE 2013-3587 (BREACH attack)

ref: http://breachattack.com/

Our scanner provider asked for an official response from cPanel regarding this because the scan indicated port 2087, 2083 and 2096 are vulnerable to this attack.

Quote:
"BREACH attack requires HTTP compression, reflection of user input in response headers, and reflection of secrets in response headers. If cPanel does not implement all three of those things, the site is not susceptible. Please reach out to cPanel to confirm and send us their response."

 

[cPanelLauren]

Hi @vpswing


That's a pretty old vulnerability, I am curious if you have made any customizations on your ciphers? What is the output of the following?

cat /var/cpanel/conf/cpsrvd/main

 

[vpswing]

Hi @vpswing


That's a pretty old vulnerability, I am curious if you have made any customizations on your ciphers? What is the output of the following?

cat /var/cpanel/conf/cpsrvd/main

It showed 'no such file or directory'

 

[vpswing]

In the /etc/apache2/conf/httpd.conf file:

    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    SSLProtocol TLSv1.2
    SSLPassPhraseDialog  builtin

    <IfModule socache_shmcb_module>
        SSLUseStapling On
        SSLStaplingCache shmcb:/run/apache2/stapling_cache_shmcb(256000)

        # Prevent browsers from failing if an OCSP server is temporarily broken.
        SSLStaplingReturnResponderErrors off
        SSLStaplingErrorCacheTimeout 60
        SSLStaplingFakeTryLater off
        SSLStaplingResponderTimeout 3
        SSLSessionCache shmcb:/run/apache2/ssl_gcache_data_shmcb(1024000)
    </IfModule>
    <IfModule !socache_shmcb_module>
        SSLSessionCache dbm:/run/apache2/ssl_gcache_data_dbm
    </IfModule>

    SSLSessionCacheTimeout  300
    Mutex                   file:/run/apache2 ssl-cache
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin

 

[cPanelLauren]

cPanel uses a different cipher suite for its webserver which runs over cpsrvd than apache does. Can you go to WHM>>Service Configuration>>cPanel Web Services Configuration and click "Save" then run the same command again?

I ask because the default cipher list should be PCI compliant and I am curious if what you're using is older than the current default. You could also potentially compare by checking against the v88 defaults:

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

 

[vpswing]

It now shows:
---
SSLCipherList: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLVersion: SSLv23:!SSLv2:!SSLv3:!TLSv1:!TLSv1_1
VERSION: '1.2'

Just a thought - from what I understand about the BREACH vulnerability - it can be mitigated by disabling TLS/SSL-level compression.
Does the above cipher disables TLS/SSL compression?

(the previous time when I ran the command 'cat /var/cpanel/conf/cpsrvd/main' - and it showed file not found, what cipher was cPanel webservice using then?)

Thanks

 

[cPanelLauren]

My goal was to rule out some old cipher or communication issue, yours are fine. BREACH is related to compression but it is alarming that the PCI scanning company would flag this specific issue. As far as I was ever aware the CVE only affects HTTP not HTTPS and all ports you noted only accept HTTPS communication. There was an old case on this and here's what it had to say:

Our CSRF tokens should be enough to mitigate BREACH attacks since they are used on all pages with sensitive information. CSRF tokens are listed as a valid way to protect against this vuln on http://breachattack.com/.
There are several tactics for mitigating the attack. Unfortunately, we are unaware of a clean, effective, practical solution to the problem. Some of these mitigations are more practical and a single change can cover entire apps, while others are page specific.The mitigations are ordered by effectiveness (not by their practicality - as this may differ from one application to another).Disabling HTTP compression
Separating secrets from user input
Randomizing secrets per request
Masking secrets (effectively randomizing by XORing with a random secret per request)
Protecting vulnerable pages with CSRF
Length hiding (by adding random number of bytes to the responses)
Rate-limiting the requests

Even the site you note specifically notes HTTP compression not HTTPS.

BREACH
While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying gzip to allow for explicit separation of compression contexts in SPDY), BREACH attacks HTTP responses. These are compressed using the common HTTP compression, which is much more common than TLS-level compression. This allows essentially the same attack demonstrated by Duong and Rizzo, but without relying on TLS-level compression (as they anticipated).

 

[vpswing]

Thank you Lauren! Appreciate your/cPanel's response to this issue.

Best regards,
Adrian

 

[juanregres4]

How did you solve the problem to get certified?