In Progress [CPANEL-26253 ] PCI compliance failure due to unsecured Horde cookies

[Brian Lack]

I am running cPanel WHM v78.0.16 and have disabled Horde entirely. These unsecure Horde cookies are suddenly being picked up by my PCI scanning provider (Clone Systems ASV) as a failure:

• Set-Cookie:
  Horde=expired; HttpOnly; domain=.sub.domain.com; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2087
• Set-Cookie:
  horde_secret_key=expired; HttpOnly; domain=.sub.domain.com; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2087

Their solution: Set the 'secure' attribute for any cookies that are sent over a ssl/tls connection.

This is the same issue brought up a year ago in this thread:

Unsecure cookie still getting sent even though service disabled

Changing "Require SSL for cPanel Services" does not make a difference.

It would be nice if cPanel stopped sending these cookies or set the secure flag, as surely more people will now be having PCI compliance issues.

 

[cPanelLauren]

Hi @Brian Lack

Based on the previous thread that was a false positive. Initially though it was asked that the previous client open a ticket to rule that out.
Can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved.


Thanks!

 

[Brian Lack]

Thanks! Support Request ID is: 11663299

 

[cPanelLauren]

Hello @Brian Lack


I checked in on this ticket this morning and found that the analyst did open an internal case for the issue: CPANEL-26253

The workaround though is that for PCI compliance purposes, this may be able to be reported as a false positive since the connection is forced to use SSL.

I will update this thread with further information on the case when it is available.

Thanks!

 

[cih997]

@cPanelLauren @cPRex did you ever solve this issue?

I tried disabling Horde completely, added cookie_httponly and related options to PHP.ini files as well as headers to the apache config but these two cookies are present and are not secure flagged:

< Set-Cookie: Horde=expired; HttpOnly; domain=.domain.com; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2083
< Set-Cookie: horde_secret_key=expired; HttpOnly; domain=.domain.com; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2083

Is there any workaround / method to remove those two cookies completely from WHM / cPanel? or at least to add "secure" flag somehow?

cPanel Version 96.0 (build 8)

 

[cPRex]

I don't have any updates on my end that would remove the cookies. I would recommend trying what Lauren stated by letting the PCI vendor know the connection does redirect to SSL:

"The workaround though is that for PCI compliance purposes, this may be able to be reported as a false positive since the connection is forced to use SSL."

 

[cih997]

Thank you @cPRex

Unfortunately this is not an option, these cookies must have "secure" flag.

I'm trying to modify apache2 headers via Apache Configuration -> Include Editor however any change made to any (pre main, pre virtualhost, post virtualhost) is not reflected on cPanel nor WHM login pages. This works for user accounts websites only.

Is there any other way to modify apache2 headers for cPanel and WHM login pages?

 

[cPRex]

I don't have any other way to modify those headers on my end.

Our development team sent me some additional details on this, and I've copied it all here:

"PCI Audits may be mistaken in identifying these cookies as a security concern. Their purpose is to invalidate the previously used cookies, after a failed authorization attempt. On successful authentication, a secure cookie will be used.
It's considered a false positive and should be requested to be marked as such by the PCI vendor.
A better way to explain this...
Because cPanel should only return an invalid non-secure cookie when it is only accessed via HTTPS, and because we recommend and default to not allowing insecure webmail logins, we do not consider the use of a non-secure cookie here to be a security concern.
To phrase the above another way, the insecure cookies are only transmitted in the event we need to invalidate previously set cookies (i.e. authorization has failed).
Therefore, the PCI Audit may be mistaken in identifying these cookies as a security concern. Their purpose is to invalidate the previously used cookies, after a failed authorization attempt. On successful authentication, a secure cookie will be used."

 

[limpopo]

I need to set flag secure to cookie horde_secret_key
I try to find working solution but all not work
I try to find variable horde_secret_key in files but didnt find
I didnt find even files of horde webmail
how to achive this?

 

[cPRex]

@limpopo - Horde is removed in cPanel 108 - which version of cPanel are you using?

 

[limpopo]

@limpopo - Horde is removed in cPanel 108 - which version of cPanel are you using?

I use cPanel Version 108.0.14
but when I open ip:2096 I get webmail login form, and it set cookie horde_secret_key, why?

 

[cPRex]

Thanks for the additional details. We have some more information about this here:

In Progress - CPANEL-42515 - PCI Scan complaint about Web Server Predictable Session ID Vulnerability with port 2087 / tcp over ssl

Yesterday’s PCI Scan by Sysnet indicated a Web Server Predictable Session ID Vulnerability with port 2087 / tcp over ssl. The details of the scan noted that the cookies for roundcube_sessid, roundcube_sessauth, Horde, horde_secret_key, PPA_ID, and imp_key, all consisted of common characters...

forums.cpanel.net

and our team is working on getting that fixed.

 

[TOne1]

Vulnerability Detection Result
The cookies: Set-Cookie: Horde=***replaced***; HttpOnly; domain=.www.xxx.de;
expires=Thu ,→, 01-Jan-1970 00:00:01 GMT; path=/; port=2096
Set-Cookie: horde_secret_key=***replaced***; HttpOnly; domain=.www.xxx.de;
,→expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2096 are missing the "Secure" cookie attribute.

 

[cPRex]

@TOne1 - the recent case I linked will fix that issue once it is resolved.

 

[TOne1]

@cPRex,
any news on this?

Issue still occurs in monthly vulnarability scans of security certificate.

Best,
T1

 

[cPRex]

I do see that a development team has picked up the case, but I don't have any other details than that at this time.