Is cockpit vulnerable to clickjacking? [CVE-2021-3660]

[rrandecker]

Through a security scan, I was notified:

The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions.

Suggested solution is:

Return the X-Frame-Options or Content-Security-Policy (with the 'frame-ancestors' directive) HTTP header with the page's response.

Is there a way to do this through the config in cockpit? or is there some other reason it is not subject to clickjacking?

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1980688 (plus a few dependent ones for the individual packages in Fedora and RHEL 8/9)

[martinpitt]

You are already the second person to report this recently. Apparently embedding as we document it is not en vogue any more..

We could default to X-Frame-Options: sameorigin (which should at least retain the reverse-proxy case, like in Foreman), and provide an option in cockpit.conf to open it up further.

[martinpitt]

@stefwalter, @mvollmer : What do you think about the above proposal? I'm afraid the discussions and goals about embedding happened before my time, so I'm a bit afraid of breaking an important use case.

[rrandecker]

I think your proposal sounds reasonable.
I am not an expert in the security, just received the scan result, and wanted to know how to remove the security risk.
Is there a way to set X-frame-options:same origin in Cockpit version 238?
I am using cockpit on RHEL8.4, and then adding a few pages for additional capabilities specific to my application... I was surprised to see security scan failures reported from cockpit.

[martinpitt]

No, there is no way to set extra headers.

[martinpitt]

I tried to run python3 -m http.server in https://github.com/cockpit-project/cockpit/tree/main/test/verify/files/embed-cockpit , and opened http://localhost:8000 . I select http://127.0.0.1:9090 in the input line, then "full server", and try to log in. PAM works, but the web page immediately goes back to the login screen without an error message. I tested this on RHEL 8.4, 8.5, and Fedora 34.

Embedding currently works as part of a cockpit web page (like on embed-cockpit example) for the same domain -- but as soon as I choose a different one like 127.0.0.2:9091 (our test VMs), it fails:

Content Security Policy: The page’s settings blocked the loading of a resource at http://127.0.0.2:9091/cockpit/@localhost/system/terminal.html (“default-src”).

All our Cockpit pages have this relatively strict C-S-P.

It looks like embedding cockpit across different origins silently broke some unknown time ago (whether this is due to new browser restrictions or some regression in cockpit-ws I can't say yet). So can you actually exploit this right now? I.e. embed a cockpit frame into a page from a different origin, and make it actually work?

[martinpitt]

See PR #16342, where I am currently investigating this, wrote test cases for both cases (same and cross origin), and will add the X-Frame-Options. However, I just can't for the life of me reproduce the bug that you can show authenticated cockpit frames on a different-origin page. I need some help with this, I also asked in https://bugzilla.redhat.com/show_bug.cgi?id=1980688#c17

[rrandecker]

I did not reproduce a bug.. I had the result of a Nessus scan, which showed the potential vulnerability in the report.
My understanding is that it could allow the cockpit page to be loaded into an iframe and click jacking works by having an invisible page over the cockpit page to take the clicks instead of getting them to the cockpit page, which would allow them to perform malicious behaviors.

My purpose of opening this ticket is to find if this is a real vulnerability, and how to prevent it if it is.

Nessus report shows:
Web Application Potentially Vulnerable to Clickjacking

Synopsis
The remote web server may fail to mitigate a class of web application vulnerabilities.

Description
The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions.

X-Frame-Options has been proposed by Microsoft as a way to mitigate clickjacking attacks and is currently supported by all major browser vendors.

Content-Security-Policy (CSP) has been proposed by the W3C Web Application Security Working Group, with increasing support among all major browser vendors, as a way to mitigate clickjacking and other attacks. The 'frame-ancestors' policy directive restricts which sources can embed the protected resource.

Note that while the X-Frame-Options and Content-Security-Policy response headers are not the only mitigations for clickjacking, they are currently the most reliable methods that can be detected through automation. Therefore, this plugin may produce false positives if other mitigation strategies (e.g., frame-busting JavaScript) are deployed or if the page does not perform any security-sensitive transactions.

See Also
http://www.nessus.org/u?399b1f56
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
https://en.wikipedia.org/wiki/Clickjacking

Solution
Return the X-Frame-Options or Content-Security-Policy (with the 'frame-ancestors' directive) HTTP header with the page's response.
This prevents the page's content from being rendered by another site when using the frame or iframe HTML tags.

Risk Factor
Medium
CVSS v2.0 Base Score
4.3 (CVSS2#AV:N/AC:M/Au:N/C:N/I:P)

References

XREF CWE:693

Plugin Information
Published: 2015/08/22, Modified: 2017/05/16

Plugin Output
xxx.xxx.xxx.xxx (tcp/9090)

The following pages do not use a clickjacking mitigation response header and contain a clickable event :

• https://xxx.xxx.xxx.xxx:9090/

[martinpitt]

Thanks @rrandecker! I will add the X-F-O, I was mostly just interested in evaluating the scope and severity, whether I was missing a case where this actually can happen.

[rrandecker]

Which redhat cockpit versions will have the X-F-O?
Is there existing protection from cross clicking attack that I can state it has been tested and cross clicking is prevented in releases before the X-F-O is added?

[martinpitt]

@rrandecker : Initially, 8.6/9.0 final. I am still investigating how much of an actual problem this is, i.e. whether we need to backport this to at least 8.5 as well.

As I mentioned, I am currently unable to get anything else besides the login page when doing a cross-domain frame embedding (which would be "harmless enough" IMHO, albeit a bit confusing). However, judging by https://bugzilla.redhat.com/show_bug.cgi?id=1980688 it is likely that I am missing something.

[rrandecker]

Is this being patched back to RHEL 8.4 version of cockpit. or did you find clickjacking only gets you back to the login page?

[martinpitt]

@rrandecker: I just made https://bugzilla.redhat.com/show_bug.cgi?id=1980688#c25 public with some details. In short, the SameSite: strict cookie policy from commit 46f6839 (aka cockpit 236) addressed most of this, so in an embedded frame from a different host name/IP address you can only ever get the login page, no authenticated frames. IMHO this mitigates most of the "interesting" aspects of clickjacking.

That means that this only works in RHEL ≤ 8.3, but RHEL 8.4+ is mostly safe already.