Unsecure cookie still getting sent even though service disabled

[syamsudin]

Hi,

We have some issues where we have disabled all web-based email client (Roundcube, Horde, etc) but our PCI-DSS scan still get the cookie with no secure attribute related to it. Does that mean disabling them in WHM doesn't get rid of them? How do we solved this to get compliant, do we need to disable them manually somewhere within cPanel source?

For example this is the result from an nmap scan:

2083/tcp open ssl/radsec?
| fingerprint-strings:
| GetRequest:
| HTTP/1.0 401 Access Denied
| Connection: close
| Content-Type: text/html; charset="utf-8"
| Date: Sun, 28 Jan 2018 23:10:19 GMT
| Cache-Control: no-cache, no-store, must-revalidate, private
| Pragma: no-cache
| WWW Authenticate: Basic realm="cPanel"
| Set-Cookie: cprelogin=no; HttpOnly; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2083; secure
| Set-Cookie: cpsession=REMOVED; HttpOnly; path=/; port=2083; secure
| Set-Cookie: roundcube_sessid=expired; HttpOnly; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2083; secure
| Set-Cookie: roundcube_sessauth=expired; HttpOnly; domain=REMOVED; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2083; secure
| Set-Cookie: Horde=expired; HttpOnly; domain=.REMOVED ; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; port=2083; secure
| Set-Cookie: horde_secret_key=exp
| HTTPOptions:
| HTTP/1.0 401 Access Denied
| Connection: close
| Content-Type: text/html; charset="utf-8"
| Date: Sun, 28 Jan 2018 23:10:20 GMT
| Cache-Control: no-cache, no-store, must-revalidate, private
| Pragma: no-cache
| WWW Authenticate: Basic realm="cPanel"
|
In the first nmap scan and in the Alienvault scan, the cookie for Horde exists even though we have disabled it and this brings issue with our PCI-DSS scan since it's missing secure attribute. I'm looking for suggestions to get rid of this cookie altogether.

Thanks!​

 

[cPanelMichael]

Hello,

You should be able to address the "unsecure cookie" report by enabling the "Choose the closest matched domain for which that the system has a valid certificate when redirecting from non-SSL to SSL URLs. Formerly known as “Always redirect to SSL/TLS”" option under the "Redirection" tab in "WHM >> Tweak Settings". Can you verify if that option helps?

Thank you.

 

[syamsudin]

Hello,

You should be able to address the "unsecure cookie" report by enabling the "Choose the closest matched domain for which that the system has a valid certificate when redirecting from non-SSL to SSL URLs. Formerly known as “Always redirect to SSL/TLS”" option under the "Redirection" tab in "WHM >> Tweak Settings". Can you verify if that option helps?

Thank you.

Hi, thanks for replying.

We already set that option to 'On' since before the scan started, but it still detects the unsecure cookies. I figured we can just disabled the Horde entirely, there should be no cookies set right? Is there any way we can remove the Horde from starting up aside from disabling it from the 'Tweak Settings > Mail > Enable Horde Webmail > Off'?

Thanks!

 

[cPanelMichael]

Hello,

It's possible this is a false positive. Could you open a support ticket using the link in my signature so we can take a closer look?

Thank you.

 

[syamsudin]

Hello,

It's possible this is a false positive. Could you open a support ticket using the link in my signature so we can take a closer look?

Thank you.

Tried to open one, unfortunately it tells me another vendor provides my license and if I don't contact them first, the issue will take much longer time to resolve. Can I just skip the vendor?

 

[syamsudin]

Hello,

It's possible this is a false positive. Could you open a support ticket using the link in my signature so we can take a closer look?

Thank you.

After further checking, I found where the cookie is coming from and I am now more confused than before. Please take a look at the screenshot below:



For testing, I accessed the secure webmail URL, and it seems like the response are sending out various cookies (albeit expired) and two of them were not secure over HTTPS which the scan picks up.

Maybe we can rule this out as false positive (ie. the purpose is to reset/clear sessions), but can we get a confirmation from cPanel themselves so we can communicate this over to our SA? But shouldn't the cookie must be marked secure when sent over HTTPS?

Thanks!

 

[cPanelMichael]

Hello,

I found a similar report of this issue in a previous support ticket. The conclusion in that support ticket was that it's normal to see that information in the header, even when Horde is disabled. As I understand, the "unsecure cookie" message is a false positive when "Require SSL for cPanel Services" is enabled under the "Security" tab in "WHM >> Tweak Settings". That said, feel free to send me a private message with a screenshot of the specific PCI failure report so I can take a closer look at exactly what it's stating.

Thank you.

 

[syamsudin]

Hello,

I found a similar report of this issue in a previous support ticket. The conclusion in that support ticket was that it's normal to see that information in the header, even when Horde is disabled. As I understand, the "unsecure cookie" message is a false positive when "Require SSL for cPanel Services" is enabled under the "Security" tab in "WHM >> Tweak Settings". That said, feel free to send me a private message with a screenshot of the specific PCI failure report so I can take a closer look at exactly what it's stating.

Thank you.

I tested with disabling the "Require SSL for cPanel Services" and the insecure cookie are still there on cPanel Services via SSL.

I can't find any link to PM you, so I attached the file here. Only relevant info is shown and all else redacted/removed. Basically this is an AlienVault vulnerability scan report that is used for PCI-DSS assessment. Thanks!

 

[syamsudin]

So I guess it's completely safe to mark this as false positive as advised from cPanel instead?

 

[cPanelMichael]

Hello,

It looks like a false positive from what I can see, but feel free to open a support ticket so we can take a closer look. You should be able to still open a ticket directly with us if necessary, despite the notice about contacting your license provider first.

Thank you.